CAPITULO 5 DESARROLLO DE DATOS

5 Desarrollo de datos

El desarrollo de datos es la tercera Función de la Gestión de Datos en el marco

de gestión de datos que se muestra en las figuras 1.3 y 1.4. Es la segunda
función de gestión de datos que interactúa con y está influenciado por la
función de Gobierno de Datos. El Capítulo 5 define la función de desarrollo de
datos y explica las actividades y conceptos involucrados en el desarrollo de
datos.

5.1 Introducción
El desarrollo de datos es el análisis, diseño, implementación, despliegue y
mantenimiento de soluciones de datos para maximizar el valor de los recursos
de datos a la empresa. El desarrollo de datos es el subconjunto de actividades
del proyecto dentro del Ciclo de Vida de Desarrollo de Sistemas (SDLC)
centrado en la definición de los requisitos de datos, el diseño de los
componentes de la solución de datos y la implantación de estos componentes.
Los componentes primarios de la solución de datos son las bases de datos y
otras estructuras de datos. Otros componentes de la solución de datos incluyen
los productos de información (pantallas e informes) y las interfaces de acceso
a los datos.
El contexto de la Función de Desarrollo de Datos se muestra en el diagrama de
contexto en la Figura 5.1
Los miembros del equipo del proyecto deben colaborar entre sí para el diseño
de soluciones efectivas.
 Los administradores de datos de negocios y expertos en la materia
(SMEs) proporcionan los requerimientos del negocio de datos e
información, incluyendo las reglas de negocio y la calidad de datos
esperada, y luego validan que se hayan cumplido estos requisitos.
 Los arquitectos de datos, analistas y administradores de bases de datos
tienen la responsabilidad principal de diseño de base de datos. Los
administradores de bases de datos colaboran con los desarrolladores de
software para definir los servicios de acceso a datos en
implementaciones de arquitecturas orientadas a servicios (SOA) en
capas.
 Los arquitectos y desarrolladores (ambos especialistas en integración
de aplicaciones y datos) de software tienen la responsabilidad principal
 de captura de datos y diseño de uso dentro de los programas, así como el
diseño de la interfaz de usuario para productos de información (pantallas
e informes impresos).

5.2 Actividades y conceptos

Las actividades necesarias para llevar a cabo la función de desarrollo de datos
se describen a continuación.

5.2.1 Ciclo de Vida de Desarrollo de Sistemas (SDLC)

Las actividades de desarrollo de datos se producen en el contexto de los
esfuerzos de desarrollo y mantenimiento de sistemas, conocidos como el ciclo
de vida de desarrollo de sistemas (SDLC). Los proyectos administran la mayor
parte de estos esfuerzos. Un proyecto es un esfuerzo organizado para lograr
algo. Un esfuerzo de mantenimiento muy pequeño se puede completar en un
día. Proyectos muy grandes de múltiples fases pueden tomar años en
completarse.

Figura 5.1 Diagrama de contexto de desarrollo de datos

Los proyectos de desarrollo y mantenimiento de sistemas realizan actividades
seleccionadas dentro del ciclo de vida de desarrollo de sistemas. Las fases del
SDLC representan pasos de alto nivel comúnmente adoptados para
implementar los sistemas, como se muestra en la Figura 5.2. No hay una
descripción estandarizada de estas etapas, pero en general, el SDLC incluye
las siguientes actividades de especificación e implementación:
  Planificación de proyectos, incluyendo la definición del alcance y la
justificación del caso de negocio.
 Análisis de Requerimientos.
 Diseño de soluciones.
 Diseño Detallado.
 Construcción de componentes.
 Pruebas, incluyendo las unitarias, de integración, de sistema, de
rendimiento y de aceptación.
 Preparación de la implementación, incluyendo el desarrollo de
documentación y capacitación.
 Instalación e implementación, incluyendo prueba piloto y puesta en
marcha.

Figura 5.2 El Ciclo de Vida de Desarrollo de Sistemas (SDLC)

Los esfuerzos de mantenimiento del sistema generalmente siguen también los
mismos procesos de alto nivel del SDLC en una secuencia muy rápida,
realizando análisis, diseño, codificación, prueba y despliegue en pequeñas
cantidades.
Muchas organizaciones han adoptado métodos SDLC que integran sistemas de
métodos y técnicas de desarrollo en un enfoque integral de desarrollo de
sistemas. Los métodos guían la planificación y el rendimiento de proyectos de
desarrollo de sistemas. La mayoría de los métodos recomiendan tareas
detalladas y técnicas específicas para realizar actividades dentro de cada etapa
del SDLC. Estas tareas y técnicas crean una serie de entregables de modelado
de datos cuyo último fin es un sistema implementado. Las salidas de tareas
anteriores sirven como entradas guiando a tareas subsecuentes.
Diferentes métodos representan el SDLC de diferentes maneras, cada una con
su propio uso distintivo de términos. Algunos métodos definen un enfoque en
cascada a la realización de las etapas SDLC. Algunos métodos definen un
espiral, enfoque iterativo. Estos métodos ofrecen soluciones completas en
forma incremental realizando las etapas del SDLC en varias fases del
proyecto, guiados algo de planificación de alto nivel, análisis y diseño.
Los sistemas de información capturan y distribuyen información (datos en
contexto pertinente y un marco de tiempo) para apoyar las funciones de
negocio. Estas funciones van desde la planificación estratégica hasta el
rendimiento operativo. Los almacenes de datos y productos de información
son componentes integrales de todos los sistemas de información. Un proyecto
de desarrollo de sistemas eficaz mantendrá un énfasis equilibrado en los datos,
procesos y tecnología.

5.2.2 Estilos de modelado de datos

Hay diferentes métodos de modelado disponibles, cada uno con diferentes
convenciones o estilos de diagramas. La sintaxis de cada uno de estos estilos
es ligeramente diferente. Mientras que todos los modelos de datos utilizan
cajas y líneas, cada estilo utiliza símbolos y contenido de la caja diferente para
denotar las especificaciones detallas. La Guía DAMA-DMBOK ofrece una
muy breve introducción a estos estilos.
 IE: El estilo más común de diagramas de modelado de datos es la
sintaxis de “ingeniería de la información” (IE), llamada así porque fue
popularizado por James Martin en sus influyentes libros capacitaciones
en Ingeniería de la Información. La notación IE utiliza tridentes o “patas
de gallo”, junto con otros símbolos, para representar cardinalidad.
 IDEF1X: Esta es una sintaxis alternativa de modelado de datos
desarrollado originalmente para el uso de la Fuerza Aérea de Estados
Unidos, el uso de los círculos (algunos oscurecidos, algunos vacíos) y
líneas (algunas sólidas, otras de puntos) en lugar de “patas de gallo”
para comunicar significados similares. Los diagramas de procesos
IDEF0 a menudo utilizan la notación IDEF1X.
 ORM: Modelado de Roles de Objetos es un estilo de modelado
alternativo con una sintaxis que permite la especificación muy detallada
de la relación de datos y reglas de negocio. Los diagramas ORM
presentna tanta información que el consumo efectivo por lo general
requiere puntos de vista pequeños en el área, con un menor número de
entidades de negocios en un solo diagrama. ORM no es ampliamente
utilizado, pero sus defensores abogan fuertemente sus beneficios. ORM
es particularmente útil para el modelado de relaciones de negocio
complejo.
 UML: El Lenguaje de Modelado Unificado es un conjunto integrado
de convenciones de diagramación para formas diferentes de modelado.
 Grady Booch, Ivar Jacobsen y James Rumbaugh desarrollaron UML
para estandarizar el análisis y diseño orientado a objetos. UML ha sido
ampliamente adoptado, logrando efectivamente este propósito. UML es
ahora ampliamente utilizado en muchos métodos de SDLC y ha sido
adoptado como estándar por muchas organizaciones.
UML define varios tipos de modelos y diagramas. Los diagramas de clases se
parecen mucho a otros estilos de modelo de datos. Además de software
orientado a objetos los modelos semánticos para servicios basados en web en
XML suelen utilizar los diagramas de clases UML. De hecho el modelado
conceptual, lógico, e incluso el físico puede utilizar diagramas de clases de
UML
Algunos profesionales no ven la necesidad o valor de modelar objetos y datos
por separado. Los modelos de clases de objetos conceptuales son equivalentes
a los modelos de datos conceptuales. Sin embargo, los modelos de datos
lógicos y físicos suelen diferir sustancialmente de los diseños de programas
orientados a objetos lógicos y físicos. Los modelos de datos lógicos
normalizan atributos de datos, mientras que los modelos de objetos no lo
hacen. Los atributos de un objeto representan los datos en la memoria del
programa, mientras que los atributos de un modelo físico de datos representan
los datos almacenados en una base de datos, por lo general como columnas de
tablas de bases de datos relacionales. Reconociendo estas diferencias, la
mayoría de los profesionales de datos prefieren modelar datos y / o bases de
datos en modelos separados con diferentes estilos de diagramas.
Cuando se usan sistemáticamente, las diferentes convenciones de diagramas
pueden diferenciarse rápidamente y comunicar el propósito de cada modelo.
Por ejemplo, algunos profesionales utilizan la notación IE para el modelado de
datos lógicos y utilizan IDEF1X para el modelado de datos físicos,
especialmente en el modelado dimensional. Sin embargo, esto es confuso para
los administradores de datos de negocios que repasan diferentes tipos de
modelos. Los administradores de datos no necesitan convertirse en
modeladores de datos, pero deben tener fluidez en la lectura e interpretación
de la convención de diagramación primaria.

5.2.3 Modelado de datos, análisis y diseño de soluciones

El modelado de datos es un método de análisis y diseño utilizado para 1)
definir y analizar requerimientos de datos y 2) diseñar las estructuras de datos
que soportan estos requerimientos. Un modelo de datos es un conjunto de
especificaciones de datos y diagramas relacionados que reflejan los
requerimientos de datos y los diseños. En su mayor parte, el modelado de
datos conceptual y modelado de datos lógicos son actividades del análisis de
requerimiento, mientras que el modelado de datos físicos es una actividad de
diseño.
Un modelo es una representación de algo en nuestro entorno. Se hace uso de
símbolos estándar que permiten rápidamente captar su contenido. Los mapas,
organigramas y planos de construcción son ejemplos de modelos en uso de
todos los días. Piense en un modelo de datos como un diagrama que utiliza
texto y símbolos para representar los elementos de datos y las relaciones entre
ellos. De hecho, un solo diagrama puede ser una de las varias vistas previstas
un único modelo de datos integrado. Más formalmente, un modelo de datos es
la colección integrada de especificaciones y diagramas relacionados que
representan las necesidades de datos y diseños.
Aunque existen técnicas y procesos bien definidos, es un arte hacer que los
datos estén disponibles en formas utilizables para una variedad de diferentes
aplicaciones, así como visualmente comprensible. El modelado de datos es un
proceso complejo que implica interacciones entre las personas y con la
tecnología, que no comprometan la integridad o la seguridad de los datos. Los
buenos modelos de datos expresan con precisión y comunican las necesidades
de datos y el diseño de una solución de calidad. Algunos diagramas de
modelos intentan comunicars demasiados detalles, lo que reduce su eficacia.
Dos fórmulas guían el enfoque de modelado:
 Propósito + audiencia = entregables.
 Entregables + recursos + tiempo = enfoque.
El propósito de un modelo de datos es facilitar:
 Comunicación: Un modelo de datos es un puente hacia la comprensión
de los datos entre las personas con diferentes niveles y tipos de
experiencia. Los modelos de datos nos ayudan a comprender un área de
negocio, una aplicación existente, o el impacto de la modificación de
una estructura existente. Los modelos de datos también pueden facilitar
la formación de nuevos negocios y / o personal técnico.
 Formalización: Un modelo de datos documenta una definición única y
precisa de las necesidades de datos y los datos relacionados con Reglas
de Negocio.
 Alcance: Un modelo de datos puede ayudar a explicar el contexto de
datos y el alcance de los paquetes de aplicaciones compradas.
Los modelos de datos que incluyen los mismos datos pueden diferir por:
 Alcance: La expresión de un punto de vista acerca de los datos en
términos de función (vista de negocio o vista de aplicación), el dominio
 (proceso, departamento, división, empresa, o vista de la industria) y el
tiempo (estado actual, futuro a corto plazo, el futuro a largo plazo).
 Enfoque: Conceptos básicos y críticos (vista conceptual), detallados
pero independientes del contexto (vista lógica), u optimizados para una
tecnología específica y utilizan (vista física).
Utilice modelos de datos para especificar los datos requeridos para satisfacer
las necesidades de información. Los datos fluyen a través de los procesos de
negocio empaquetados en productos de información. Los datos contenidos en
estos productos de información deben cumplir con los requerimientos del
negocio. El modelado de datos es, en ese sentido, una actividad de análisis,
reflejando requerimientos del negocio. Sin embargo, el modelado de datos
presenta oportunidades creativas en cada paso, por lo que es, al mismo tiempo,
una actividad de diseño. En general, hay más análisis involucrados en el
modelado conceptual de datos y más diseño involucrado en el modelado de
datos físicos, con una mezcla más equilibrada de ambos en el modelado de
datos lógicos.
[Link] Analizar los requisitos de información
La información son datos en contexto que tienen relevancia y son oportunos.
Para identificar las necesidades de información, tenemos que identificar
primero las necesidades de información de negocios, a menudo en el contexto
de uno o más procesos de negocio. Los procesos de negocio consumen como
entrada, los productos de información de salida de otros procesos de negocio.
Los nombres de estos productos de información a menudo identifican un
vocabulario de negocios esencial que sirve de base para el modelado de datos.
Independientemente si los procesos o datos se modelan de forma secuencial
(en cualquier orden), o al mismo tiempo, el análisis y el diseño eficaz debe
garantizar una visión relativamente equilibrada de los datos (nombres) y
procesos (verbos), con el mismo énfasis en el proceso y el modelado de datos.
Normalmente los proyectos comienzan con una solicitud de proyecto y la
definición de una carta del proyecto que define los objetivos del proyecto, los
resultados y los límites de alcance. Los planes iniciales del proyecto estiman
los recursos, esfuerzos, tiempo y costo requeridos para lograr los objetivos del
proyecto. Cada carta del proyecto debe incluir objetivos específicos de datos e
identificar los datos dentro de su ámbito de aplicación. La referencia a un
modelo de datos de la empresa proporciona el vocabulario para definir el
alcance de datos del proyecto con eficacia.
El análisis de requerimientos incluye la obtención, organización,
documentación, revisión, el refinamiento, la aprobación y control de cambios
de los requerimientos del negocio. Algunos de estos requisitos se identifican
las necesidades de negocio de datos e información. Expresa las
especificaciones de requerimientos tanto en palabras como en diagramas.
El modelado de datos lógico es un importante medio de expresión de las
necesidades de datos de negocios. 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 creadas por las herramientas de modelado de datos.
Muchas organizaciones tienen requisitos formales - disciplinas de gestión para
orientar las declaraciones de redacción y refinación de requerimientos
formales, como, “El sistema deberá...”. Documentos de especificación de
requerimientos de datos por escrito pueden ser mantenidos utilizando
herramientas de gestión de requisitos. Sincronizar cuidadosamente el
contenido de dicha documentación con las especificaciones capturados dentro
de los modelos de datos.
Algunos métodos incluyen las actividades de planificación empresarial que
definen el modelo de datos de la empresa, utilizando técnicas tales como la
planificación de los sistemas de negocios (BSP) o la planificación de los
sistemas de información. Los métodos también pueden incluir la definición de
la arquitectura de distribución de datos en toda la empresa relacionada en la
fase de planificación. En el capítulo 4 del apartado de la arquitectura de la
administración de datos se cubren estas actividades.
[Link] Desarrollar y mantener modelos de datos conceptuales
Un modelo conceptual de datos es una perspectiva visual de alto nivel sobre
un tema de importancia para el negocio. Contiene sólo las entidades
empresariales básicas y críticas dentro de un dominio y función dada, con una
descripción de cada entidad y las relaciones entre las entidades. Los modelos
de datos conceptuales definen la semántica (sustantivos y verbos) del
vocabulario esencial del negocio. Las áreas temáticas de modelo conceptual
de datos siempre son representativas de los datos asociados a un proceso de
negocio o función de la aplicación. Un modelo conceptual de datos es
independiente de la tecnología (base de datos, archivos, etc.) y del contexto de
uso (si la entidad está en un sistema de facturación o un almacén de datos).
Incluido en un modelo conceptual de datos hay un glosario que define cada
objeto dentro del modelo conceptual de datos. Las definiciones incluyen
términos de negocio, términos de relación, sinónimos de entidad y las
clasificaciones de seguridad. Un ejemplo de un modelo conceptual de datos se
muestra en la Figura 5.3.
Figura 5.3 Ejemplo de Modelo Conceptual de Datos
Para crear un modelo conceptual de datos, comenzar con una área temática de
las áreas temáticas del modelo. Determinar qué objetos están incluidos dentro
de ésa area y cómo se relacionan entre sí. Por ejemplo, el área temática Cliente
puede contener las siguientes entidades: Titular de la Cuenta, Sub Cuenta,
Preferencia del Contacto e Información de Contacto. Un Titular de la Cuenta
se refiere a una o más Subcuentas. Cada Titular de la Cuenta tiene un conjunto
de Preferencias de Contacto y un conjunto de Información de Contacto en
cualquier momento.
Para mantener un modelo conceptual de datos, es necesario adoptar un
proceso para revisar los cambios propuestos al sistema de producción contra el
modelo conceptual. Si un proyecto implicará cambios, crear un modelo
conceptual intermedio y realizar los cambios allí. Copie los cambios de
modelo a la versión del modelo conceptual de producción del modelo
conceptual cuando implemente cambios en el sistema de producción como
parte del proceso de liberación, para asegurar que el modelo mantiene en
sintonía con la realidad actual.
[Link].1 Entidades
Una entidad de negocio es algo de interés para la organización, un objeto o un
evento. Una entidad de datos es una colección de datos acerca de algo que el
negocio considera importante y digno de captura. Una entidad es un
sustantivo:
 Un quién: persona, organización, papel, empleado, cliente, proveedor,
estudiante, partido, departamento, organismo regulador, competidor,
socio, filial, equipo, familia, hogar.
 Un qué: El producto, servicio, recursos, materia prima, producto
terminado, por supuesto, la clase.
 Un cuándo: Evento, periodo fiscal.
 Un dónde: Lugar, dirección, web, nodo de red.
 Un por qué: Política, norma, solicitud, queja, el retorno, la indagación.
 Una forma: Mecanismo, herramienta, documento, factura, contrato,
convenio, estándar, cuenta.
Una ocurrencia de entidad es la creación de una instancia de una entidad de
negocio en particular. La entidad Cliente puede tener instancias con nombre
Bob, Joe, Jane y así sucesivamente. La entidad Cuenta puede tener instancias
de la cuenta corriente de Bob, cuenta de ahorros de Bob, cuenta de corretaje
de Joe y así sucesivamente.
Una entidad puede aparecer en un modelo de datos conceptual o lógico. Las
entidades de negocio conceptuales describen las cosas sobre las que
recogemos datos, tales como Clientes, Productos y Cuenta. Las entidades de
datos lógicos siguen las reglas de la normalización y la abstracción y por lo
tanto el concepto de Cliente se convierte en varios componentes, como
Cliente, Tipo de Cliente y la Preferencia del Cliente. Los modelos de datos
físicos definen tablas que pueden o no pueden relacionarse directamente a las
entidades en un modelo lógico comparable.
Las entidades pueden ser entidades independientes o dependientes. Una
entidad independiente (o entidad central) no depende de ninguna otra entidad
para su existencia. Cada ocurrencia de una entidad independiente existe sin
hacer referencia a ninguna otra entidad en el modelo de datos. Una entidad
dependiente depende de una o más entidades para su existencia. Hay tres tipos
principales de entidades dependientes:
 Entidad por atributo/característica: Una entidad que depende de una
sola entidad padre, tal como Beneficiario del Empleado que depende de
Beneficiario.
 Entidad Asociativa/Mapeo: Una entidad que depende de dos o más
entidades, tales como Registro, que depende de un Estudiante en
particular y de un Curso.
  Entidad de Categoría subtipo/supertipo: Una entidad que es “una
especie de” otra entidad. Subtipos y supertipos son ejemplos de
generalización y herencia. Una entidad de tipo Super es una
generalización de todos sus subtipos y cada subtipo hereda los atributos
de su supertipo. Por ejemplo, un entidad Supertipo Individuo tiene
enlaces los susbtipos a Persona y Organización. Los subtipos pueden ser
solapados (no exclusiva) o no solapados (exclusivo). Una instancia de la
entidad subtipo no solapada tique que ser un sub-tipo u otro, pero no
ambos.
[Link].2 Relaciones
Las reglas de negocio definir restricciones sobre lo que puede y no
puede hacer. Las Reglas de Negocio se dividen en dos categorías
principales:
 Reglas de datos restringen cómo los datos se relaciona con otros datos.
Por ejemplo, “los estudiantes de primer año pueden inscribirse por un
máximo de 18 créditos por semestre.” Los modelos de datos se enfocan
de reglas de negocio.
 Las reglas de acción son instrucciones sobre qué hacer cuando los
elementos de datos contienen ciertos valores. Las reglas de acción son
difíciles de definir en un modelo de datos. Las reglas de negocio para la
calidad de los datos son reglas de acción y las aplicaciones las
implementan como edición y validación de entrada de datos.
Los modelos de datos expresan dos tipos principales de reglas de
datos:
 Las reglas de cardinalidad definen la cantidad de instancias de la
entidad que puede participar en una relación entre dos entidades. Por
ejemplo, “Cada empresa puede emplear a muchas personas.”
 Las reglas de integridad referencial garantizan valores válidos. Por
ejemplo, “Una persona puede existir sin trabajar para una empresa, pero
una empresa no puede existir a menos que una persona este empleada
por la empresa.”
Exprese la cardinalidad y la integridad de las reglas de negocio como
las relaciones entre las entidades de los modelos de datos. Combinar
los ejemplos anteriores para expresar la relación entre la empresa y la
persona de la siguiente manera:
 Cada persona puede trabajar para cero a muchas empresas.
 Cada empresa debe emplear de una o muchas personas.
Las etiquetas de la relación son frases verbales que describen la
reglas de negocio en cada sentido entre dos entidades, junto con las
palabras que describen los “muchos” los aspectos de cada relación
(cardinalidad) y el lado “cero o uno” de cada relación (integridad
referencial).
Una relación entre dos entidades puede ser uno de los tres tipos de
relaciones:
 Una relación uno-a-uno, dice que la entidad padre puede tener una y
sólo una entidad niño.
 Una relación uno-a-muchos, dice que la entidad padre puede tener una
o más entidades secundarias. Las relaciones uno-a-muchos son las
relaciones más comunes. En algunas relaciones uno-a-muchos, una
entidad niño debe tener un padre, pero en otras relaciones, la relación
con uno de los padres es opcional. En algunas relaciones uno-a-muchos,
una entidad padre debe tener al menos una entidad niño, mientras que en
otras relaciones uno-a-muchos, la relación a cualquier niño es opcional.
 Una relación de muchos a muchos, dice que una instancia de cada
entidad puede estar asociada con cero a muchas instancias de la otra
entidad y viceversa.
 Una relación recursiva relaciona instancias de una entidad a otras
instancias de la misma entidad. Relaciones recursivas pueden ser de uno
a uno, uno-a-muchos o muchos-a-muchos.
[Link] Desarrollar y mantener modelos de datos lógicos
Un modelo de datos lógico es una representación detallada de los
requerimientos de datos y las reglas de negocio que rigen la calidad de datos,
por lo general en apoyo de un contexto de uso específico (requisitos de la
aplicación). Los modelos de datos lógicos seguirían siendo independientes de
cualquier tecnología o de las limitaciones técnicas de implementación
específicas. Un modelo de datos lógicos a menudo comienza como una
extensión de un modelo conceptual de datos, añadiendo atributos de datos para
cada entidad. Las organizaciones deben tener estándares de nomenclatura para
orientar la asignación de nombres de objetos de datos lógicos. Los modelos de
datos lógicos transforman estructuras de modelos de datos conceptuales
mediante la aplicación de dos técnicas: la normalización y la abstracción. Un
ejemplo de un modelo lógico de datos se muestra en la Figura 5.4.
La normalización es el proceso de aplicación de normas para organizar la
complejidad del negocio en estructuras de datos estables. Se requiere una
comprensión más profunda de cada elemento de datos, para ver cada elemento
de datos en relación a cualquier otro elemento de datos. El objetivo básico de
la normalización es mantener a cada elemento de datos en un solo lugar.
Las reglas de normalización ordenan los elementos de datos de acuerdo a las
claves primarias y externas. Las reglas de normalización ordena en niveles,
donde en cada nivel se aplicará más granularidad y especificidad en busca de
las claves primarias y externas correctas. Cada nivel consta de una forma
normal por separado y cada nivel sucesivo incluye los niveles anteriores. Los
niveles de normalización incluyen:
 Primer forma normal (1NF): Asegura que cada entidad tenga una clave
principal válida, cada elemento de datos depende de la clave principal y
elimina grupos de repetición y garantiza que cada elemento de datos es
atómica (no multi-valorado).
 Segunda forma normal (2NF): Asegura que cada entidad tenga una
clave principal mínima y que cada elemento de datos dependa de la
clave primaria completa
 Tercera forma normal (3NF): Asegura que cada entidad no tenga
claves primarias ocultas y que cada elemento de datos no dependa de
elemento de datos fuera de la clave (“la clave, la clave de todo y nada
más que la clave”).

Figura 5.4 Ejemplo de Modelo de datos lógicos

  La forma normal Boyce / Codd (BCNF): Resuelve la superposición de
claves candidatas compuestas. Una clave candidata es una clave
primaria o bien una clave alternativa. ‘Compuesto’ significa más de uno
(por ejemplo, dos elementos de datos en la clave principal de una
entidad) y ‘superposición’ significa que se hay reglas de negocio ocultas
entre las claves.
 La cuarta forma normal (4NF): Resuelve todas las relaciones muchos-
a-muchos (y más allá) en pares hasta que no puedan desglosarse en
partes más pequeñas.
 La quinta forma normal (5NF): Resuelve dependencias entre las
entidades en pares básicos y todas las uniones de dependencia utilizan
partes de las claves primarias.
 La sexta forma normal (6NF): Añade objetos temporales a las claves
principales, con el fin de permitir la presentación de informes y análisis
histórico sobre los plazos.
El término modelo normalizado generalmente significa que los datos se
encuentra en 3NF. Raramente ocurren situaciones que requieran BCNF, 4NF,
5NF y 6NF; estas formas se consideran temas avanzados en el modelado de
datos.
La abstracción es la redefinición de las entidades de datos, elementos y
relaciones mediante la eliminación de los detalles para ampliar la aplicabilidad
de las estructuras de datos a una clase más amplia de situaciones, a menudo
mediante la implementación de súper-tipos en lugar de subtipos. Utilizar
un super-tipo Party Role genérico para representar los sub-tipos Cliente,
Empleado y Proveedores es un ejemplo de la aplicación de la abstracción.
Utilice la normalización para mostrar los detalles conocidos de entidades.
Utilice la abstracción cuando algunos detalles de las entidades no están
presentes o aún no descubiertos, o cuando la versión genérica de entidades es
más importante o útil que los subtipos.
[Link].1 Atributos
Un atributo es una propiedad de una entidad; un tipo de dato importante para
la empresa cuyos valores ayudan a identificar o describir una instancia de
entidad. Por ejemplo, el atributo Apellido del Estudiante describe el apellido
de cada estudiante. Los atributos se traducen en un modelo de datos físico a un
campo de un archivo o una columna de una tabla de base de datos. Los
atributos utilizan nombres de negocio, mientras que los campos y columnas
utilizan nombres técnicos que con frecuencia incluyen abreviaturas técnicas.
En un modelo de datos lógicos, las entidades de negocio representan los
nombres esenciales en el vocabulario de la organización y los atributos
representan adjetivos.
Un atributo en un modelo lógico debe ser atómico. Debe contener una y sólo
una porción de datos (hecho) que no puede ser dividida en pedazos más
pequeños. Por ejemplo, un elemento de datos conceptual llamado número de
teléfono se divide en varios elementos de datos lógicos para el código de tipo
de teléfono (casa, oficina, fax, móvil, etc.), código de país, (1 para Estados
Unidos y Canadá), código de área, prefijo, la base número de teléfono y la
extensión.
Una instancia de un atributo es el valor del atributo para una instancia de
entidad particular. La aparición de un valor de datos es una instancia de
atributo para una instancia de entidad. La instancia de elemento de datos
60106, por ejemplo, pertenece al elemento de datos Código Postal Empleado
Cliente, que existe para la instancia del cliente Bob.
Las definiciones de entidades y atributos son contribuyentes esenciales para el
valor de negocio de cualquier modelo de datos. Las definiciones de alta
calidad aclaran el significado del vocabulario de negocios y proporcionan
rigor a las relaciones de entidad que gobiernan las reglas de negocio. Las
definiciones de alta calidad ayudan a los profesionales del negocio en la toma
de decisiones de negocios inteligentes y ayudan a los profesionales de IT en la
toma de decisiones inteligentes sobre el diseño de aplicaciones. Las
definiciones de datos de alta calidad presentan tres características esenciales:
la claridad, precisión y exhaustividad.
[Link].2 Dominios
El conjunto completo de todos los valores posibles para un atributo es un
dominio. Un atributo no puede contener valores fuera de su dominio asignado.
Algunos dominios tienen un número limitado de valores definidos específicos,
o límites mínimos o máximos para los números. Las reglas de negocio
también puede restringir los dominios.
Los atributos a menudo comparten el mismo dominio. Por ejemplo, una fecha
de contratación del empleado y una fecha de la orden de compra deben ser:
 Una fecha del calendario válido (por ejemplo, no el 31 de febrero).
 Una fecha que cae en un día laborable.
 Una fecha que no cae en un día festivo.
Un diccionario de datos contiene una colección de dominios y los atributos
que se relacionan con cada dominio, entre otras cosas.
[Link].3 Claves
Los atributos asignados a las entidades pueden ser o no claves. Un elemento
de datos que es clave ayuda a identificar una instancia única de una entidad de
todas los demás ya sea totalmente (por sí mismo) o parcialmente (en
combinación con otros elementos clave). Los elementos de datos que no son
clave describen la instancia de la entidad, pero no ayudan a identificarlo de
forma única.
Una llave (o clave candidata) representa uno o más atributos cuyos valores
identifican de forma exclusiva una instancia de la entidad. Una clave
compuesta es una clave que contiene dos o más atributos. Una de estas claves
candidatas se convierte en la clave principal. Sólo debe haber una clave
primaria. Todas las demás claves candidatas se vuelven claves alternativas.
Para evitar el uso de claves primarias compuestas, o atributos clave con
valores que cambian con el tiempo, se utiliza una clave sustituta. Una clave
sustituta contiene un valor generado aleatoriamente asignado a una instancia
de entidad. ‘Subrogado’ significa ‘sustituto’. Utilice una clave sustituta
cuando exista un elemento de datos únicos o un conjunto de elementos de
datos dentro de la entidad. Otros nombres para las claves sustitutas son claves
anónimas o claves no inteligentes. Tenga en cuenta que simplemente tener una
clave generada por un número secuencial en realidad todavía tiene algo de
inteligencia. Una persona puede decir en qué orden las filas se insertan en la
tabla por la secuencia, similar a un número de fila. Las claves subrogadas son
aleatorias, no secuenciales.
Una clave foránea es un atributo proporciona un enlace a otra entidad. En
pocas palabras, una clave foránea es un atributo aparece en ambas entidades
en una relación e identifica parcialmente o totalmente una o ambas entidades.
Cuando existe una relación de uno a varios entre dos entidades, la entidad en
el lado secundario de la relación hereda los atributos de clave primaria de la
entidad en el lado de los padres de la relación. La clave foránea permite la
navegación entre las estructuras de datos.
Una relación de identificación se produce cuando el atributo de la clave
foránea de una entidad padre aparece como parte de la clave primaria
compuesta de una entidad hijo. Una relación sin identificación se produce
cuando la clave foránea de una entidad padre no es un atributo clave que
describe la entidad hijo.
[Link] Desarrollar y mantener modelos físicos de datos
Un modelo de datos físico optimiza la implementación de los requerimientos
de datos detallados y las reglas de negocio en vista de las limitaciones de la
tecnología, el uso de las aplicaciones, los requisitos de desempeño y
estándares de modelado. Diseñe las bases de datos relacionales teniendo en
mente las capacidades específicas de un sistema de gestión de base de datos
específico (IBM DB2 UDB o, Oracle, Teradata, Sybase o Microsoft SQL
Server o Access). Las organizaciones deben tener estándares de nomenclatura
para orientar la asignación de nombres de objetos de datos físicos. Un ejemplo
de un modelo físico de datos se muestra en la Figura 5.5.

Figura 5.5 Ejemplo de modelo de datos físicos

El diseño del modelo de datos físico incluye tomar decisiones sobre:
 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).
 El dominio lógico, tipo de datos físico, longitud y anulabilidad de cada
columna o campo.
 Cualquier valor predeterminado para las columnas o campos,
especialmente para las restricciones NOT NULL.
  Las claves primarias y alternativas únicas e índices, incluyendo la
forma de asignar las claves.
 Implementación de pequeños conjuntos de valores de datos de
referencia en el modelo lógico, tales como a) tablas separadas de código,
b) una tabla de códigos principal compartida, o c) simplemente como
reglas o restricciones.
 Implementación entidades del modelo lógico de supertipo / subtipo en
el diseño de base de datos físicos donde los atributos de las entidades
sub-tipo “se fusionaron en una tabla que representa la entidad supertipo
como columnas anulables, o colapsando los atributos de la entidad
supertipo en una tabla para cada subtipo.
De aquí en adelante, utilizaremos el término “tablas” para referirse a tablas,
archivos y esquemas; el término “columnas” para referirse a las columnas,
campos y elementos; y el término ‘filas’ para referirse a filas, registros o
casos.
El modelado de datos físico transforma el modelo de datos lógico utilizando
varias técnicas, incluyendo:
 Desnormalización: viola de forma selectiva y con razón, las reglas de
normalización, la re-introducción de redundancia en el modelo de datos
para reducir el tiempo de recuperación de datos, potencialmente a
expensas de ocupar espacio adicional, tiempo adicional de inserción y
actualización y reducción de la calidad de datos.
 Claves sustitutas: claves suplentes no visibles para el negocio.
 Indexación: Crear archivos de índice adicionales para optimizar
determinados tipos de consultas.
 Partición: Romper una tabla o archivo verticalmente (separando
columnas en grupos) u horizontalmente (separando filas en grupos).
 Vistas: Tablas virtuales utilizadas para simplificar las consultas,
controlar acceso a los datos y cambiar el nombre de las columnas, sin la
pérdida de integridad debida a la des-normalización.
 Dimensionalidad: Creación de tablas de hechos con sus dimensiones
asociadas, estructurados como esquemas de estrella y esquemas copo de
nieve, para la inteligencia de negocios (véase el capítulo 9).

5.2.4 Diseño de Datos Detallado

El diseño detallado incluye especificaciones de implementación de base de
datos. Un diseño de base de datos física puede tomar ventaja de las funciones
y capacidades de un sistema de gestión de base de datos específica, que puede
o no estar incluido en el modelo de datos en sí únicas.
Para bases de datos relacionales, el primer entregable es la especificación del
lenguaje de definición de datos (DDL). DDL es un subconjunto del lenguaje
de consulta estructurado (SQL) que se utiliza para crear tablas, índices, vistas
y otros objetos de base de datos físicos. Para bases de datos XML, el principal
entregable de diseño es el espacio de nombres.
Un documento de diseño de base de datos completa y de alta calidad es algo
más que declaraciones DDL. En la sección [Link].3 se describe un documento
completo del diseño físico.
Colabore o no el DBA en el modelado de datos físicos, el DBA es el principal
responsable de diseño de base de datos detallada, incluyendo:
 Asegurar que el diseño cumpla con los requisitos de integridad de
datos.
 Determinar la estructura física más adecuada para albergar y organizar
los datos, ya sea relacional u otro tipo de DBMS, archivos, cubos
OLAP, XML, etc.
 Determinar las necesidades de recursos de bases de datos, como el
tamaño y la ubicación del servidor, los requisitos de espacio en disco,
los requisitos de CPU y memoria y requisitos de la red.
 Crear las especificaciones de diseño detalladas para las estructuras de
datos, tales como tablas relacionales de bases de datos, índices, vistas,
cubos de datos OLAP, esquemas XML, etc.
 Asegurar que se cumplan los requerimientos de rendimiento, incluidos
los lotes y los requisitos de tiempo de respuesta en línea para consultas,
inserciones, actualizaciones y eliminaciones.
 Diseñar el esquema de copia de seguridad, recuperación, archivo y
depuración, lo que garantiza que se cumplan los requisitos de
disponibilidad y las operaciones de mantenimiento de bases de datos
que se pueden realizar dentro de la ventana (s) de tiempo disponible
(véase el capítulo 6).
 Implementar la seguridad de datos, incluyendo la autenticación,
cifrado de necesidades, las funciones de aplicación y el acceso a datos y
actualizar los permisos que deberían ser asignados. La regla general
nunca es conceder permisos en objetos de base de datos a usuarios
individuales, sólo a los roles. Los usuarios se pueden mover dentro y
fuera de los roles según sea necesario; esto reduce en gran medida el
mantenimiento y mejora de la seguridad de los datos (véase el capítulo
7).
 Determinar esquemas de particionamiento y hash, donde sea
apropiado.
  Exigir la revisión del código SQL para asegurarse de que el código
cumple con los estándares de codificación y funcionará de manera
eficiente.
[Link].1 Diseño de base de datos física
Elija un diseño de base de datos basado tanto en la arquitectura como en
la tecnología. Base la elección de la arquitectura (por ejemplo,
relacional, jerárquico, red, objeto, esquema en estrella, copo de nieve,
cubos, etc.) en varias consideraciones:
 Si (y con qué frecuencia) los datos se actualizan.
 La organización natural de los datos.
 ¿Cómo se visualizan los datos y como se utilizan?
La elección de la tecnología de aplicación (por ejemplo,
relacionales, XML, OLAP, o tecnología de objetos) puede regirse
por muchos factores diferentes, incluyendo el tiempo que necesita
que se mantengan los datos, si deben ser integrado con otros datos
o se pasan a través del sistema o límites de aplicación y de los
requisitos de seguridad de los datos, la integridad, la capacidad de
recuperación, la accesibilidad y la reutilización.
También puede haber factores organizacionales o políticos, incluidos
los sesgos de organización y habilidades de desarrollo, que se
inclinan hacia una tecnología o proveedor en particular. Otros
factores que influyen en el diseño de base de datos física incluyen:
 Compra de licencias y requerimientos, incluyendo el DBMS, el
servidor de base de datos y cualquier acceso a los datos del lado del
cliente y herramientas de reporte.
 Los requisitos de auditoría y de privacidad (por ejemplo, la ley
Sarbanes-Oxley, PCI, HIPAA, etc.).
 Requisitos de la solicitud; por ejemplo, si la base de datos debe ser
compatible con una aplicación web o servicio web, o una herramienta en
particular de análisis o informes.
 Los acuerdos de nivel de servicio (SLA) de base de datos.
Los diseñadores de bases de datos deben encontrar las respuestas
a varias preguntas, entre ellas:
 ¿Cuáles son los requisitos de rendimiento? ¿Cuál es el tiempo máximo
permitido para una consulta para devolver los resultados, o para un
conjunto importante de cambios que se produzcan?
  ¿Cuáles son los requisitos de disponibilidad de la base de datos?
¿Cuáles es la ventana (s) de tiempo para la realización de operaciones de
base de datos? ¿Con qué frecuencia se deben realizar copias de
seguridad de bases de datos y copias de seguridad del registro de
transacciones (es decir, ¿cuál es el período más largo de tiempo, que
podemos correr el riesgo de no recuperar de los datos)?
 ¿Cuál es el tamaño esperado de la base de datos? ¿Cuál es la tasa
esperada de crecimiento de los datos? ¿En qué momento los datos
antiguos o no utilizados pueden ser archivados o eliminados? ¿Cuántos
usuarios concurrentes se prevé?
 ¿Qué tipo de virtualización de datos son necesarios para soportar los
requerimientos de aplicación, de manera tal que la base de datos no
perjudique a la aplicación?
 ¿Las demás aplicaciones necesitarán los datos? Si es así, ¿qué datos y
cómo?
 ¿Los usuarios esperan poder hacer consultas ad-hoc y sacar reportes?
Si es así, cómo y con qué herramientas?
 ¿Qué, si existe, procesos de negocio o aplicación necesita implementar
la base de datos? (por ejemplo, el código de disparador que hace
comprobación de integridad entre bases de datos y la actualización,
clases de la aplicación de base de datos encapsulados en procedimientos
o funciones, vistas de bases de datos que proporcionan recombinación
de tablas para la facilidad el uso o de propósitos de seguridad, etc.).
 ¿Existen consideraciones sobre las aplicaciones o de los
desarrolladores con respecto a base de datos, o el proceso de desarrollo
de base de datos, que deben abordarse?
 ¿El código de la aplicación eficiente? ¿Puede un cambio de código
aliviar un problema de rendimiento?
En el diseño y la construcción de la base de datos, el DBA debe mantener
los siguientes principios de diseño en mente (recuerde el acrónimo
PRISM):
 Rendimiento y Facilidad de uso: Garantizar el acceso rápido y fácil a
los datos por los usuarios autorizados en una forma utilizable y relevante
para el negocio, maximizando el valor de negocio de las aplicaciones y
datos.
 Reutilización: La estructura de la base de datos debe garantizar que,
donde sea apropiado, que múltiples aplicaciones puedan utilizar los
datos. La estructura de base de datos también debe asegurar que
múltiples los propósitos de negocios, (como el análisis de negocios,
mejora de la calidad, la planificación estratégica, gestión de relaciones
 con los clientes y la mejora de procesos) puedan utilizar los datos. Evitar
adaptar una base de datos, estructura de datos, u objeto de datos a una
única aplicación. No intentar adaptar una aplicación a una base de datos!
Los datos deben reflejar las verdaderas entidades y atributos de la
empresa, no los requisitos de una sola aplicación.
 Integridad: Los datos siempre deben tener un sentido de negocio y
valor válido, sin importar el contexto y siempre deben reflejar un estado
válido de la empresa. Hacer cumplir la integridad de datos lo más cerca
posible de los datos como sea posible y de inmediato detectar e informar
sobre violaciones de las restricciones de integridad de datos.
 Seguridad: Los datos verdaderos y exactos siempre deben estar
inmediatamente disponibles para los usuarios autorizados, pero sólo a
usuarios autorizados. Las consideraciones sobre la privacidad de todas
las partes interesadas, incluidos los clientes, socios comerciales y los
reguladores del gobierno, deben ser cumplidas. Hacer cumplir la
seguridad de datos, como la integridad de datos, lo más cerca posible de
los datos como sea posible y detectar y reportar inmediatamente
violaciones de seguridad.
 Capacidad de mantenimiento: Realizar todos los trabajos de datos a un
costo que produzca valor asegurando que el costo de crear, almacenar,
mantener, usar y disponer de los datos, no supera su valor a la
organización. Asegúrese la respuesta más rápida posible a los cambios
en los procesos y nuevos requerimientos del negocio.
Estas son algunas de las mejores prácticas recomendadas para el diseño de
base de datos física:
1. Para las bases de datos relacionales que soportan el
procesamiento de aplicaciones transacciones (OLTP), utilice un diseño
normalizado para promover la integridad de datos, la reutilización, el
buen rendimiento de la actualización y extensibilidad de datos.
2. Al mismo tiempo, utilizar vistas, funciones y procedimientos
almacenados para crear no normalizado, aplicación específica, orientado
a objetos, vistas conceptuales (virtuales) de datos. No fuerce a los
desarrolladores a trabajar a nivel de base de datos físicos, ni esquemas
de bases para las aplicaciones. El objetivo es abstraer la funcionalidad
de los datos de su estructura física y que sea lo más fácil posible para
trabajar.
3. Utilice convenciones estándar de nomenclatura y nombres
significativos y descriptivos en todas las bases de datos y objetos de
base de datos para facilitar el mantenimiento, sobre todo si las
abreviaturas son necesarias.
 4. Hacer cumplir la seguridad y la integridad de los datos a nivel
de base de datos, no en la aplicación. Esto permite la fácil reutilización
de los datos, mientras que le ahorra a los desarrolladores el trabajo de
tener que escribir y probar las restricciones a nivel de código en cada
aplicación que utilice una determinada pieza de datos.
5. Trate de mantener el procesamiento de base de datos en el
servidor de base de datos tanto como sea posible, para un máximo
rendimiento, facilidad de mantenimiento, seguridad, escalabilidad,
reducción de tráfico en la red y un menor costo de desarrollo. Por
ejemplo, aplicar todas las actualizaciones de bases de datos y consultas
SQL complejas como procedimientos almacenados en la base de datos,
en lugar de incrustar en el código de la aplicación y utilizar los cursores
del lado del servidor (en lugar de en el cliente). Usando procedimientos
almacenados hace que sea fácil de aislar y corregir los errores y
problemas de rendimiento, mejora el rendimiento y reduce una gran
medida el tráfico de red.
6. Otorgar permisos en objetos de base (tablas, vistas,
procedimientos almacenados, funciones, etc.) sólo a grupos o funciones
de aplicación, no a individuos. Esto mejora la seguridad y la facilidad de
mantenimiento.
7. No permita cualquier adaptación directa, ad-hoc de la base de
datos; hacer todas las actualizaciones de una manera controlada, a través
de procedimientos predefinidos.
[Link].2 Modificaciones de Rendimiento
Al implementar una base de datos física, considere cómo la base de datos
responderá cuando las aplicaciones hagan solicitudes para acceder y modificar
datos. Hay varias técnicas utilizadas para optimizar el rendimiento de base de
datos.
La indexación puede mejorar el rendimiento de consulta en muchos casos. El
diseñador de la base de datos debe seleccionar y definir los índices adecuados
para las tablas de bases de datos. Un índice es una ruta alternativa para
acceder a datos en la base de datos para optimizar el rendimiento de la
consulta (recuperación de datos). Los principales productos RDBMS soportan
muchos tipos de índices. Los índices pueden ser únicos o no únicos, agrupados
o no agrupados, particionados o no particionados, de columna simple o de
varias columnas, árbol-b o mapa de bits o un algoritmo hash. Sin un índice
apropiado, el DBMS volverá a leer cada fila de la tabla (exploración de tabla)
para recuperar los datos. En tablas grandes, esto es muy costoso. Trate de
construir índices en tablas grandes para soportar las consultas más frecuentes
de gestión, utilizando las columnas referenciadas más frecuentemente, en
particular las claves (primaria, alternas y extranjeras).
La desnormalización es la transformación deliberada de un modelo lógico de
datos normalizado en las tablas con los datos redundantes. En otras palabras,
se pone intencionadamente un elemento de datos en múltiples lugares. Este
proceso suele generar riesgo de errores en los datos debido a la duplicación.
Implemente controles de calidad de datos para asegurar que las copias de los
elementos de datos permanecen almacenados correctamente. Desnormalice
específicamente sólo para mejorar el rendimiento de consultas de base de
datos ya sea por cálculos de datos costosos segregando o combinando datos
para reducir el tamaño del conjunto de consultas, combinando datos para
reducir las combinaciones, o mejorando y guardando cáluculos de datos
costosos. Las técnicas de desnormalización incluyen (entre otros):
 Colapsar jerarquías (roll-up): Para reducir las combinaciones,
combinar el acceso directo de relaciones padre / hijo en una misma
tabla, repitiendo las columnas de los padres en cada fila. Esta es una
herramienta importante en el modelado dimensional (discutido en el
Capítulo 9 de Almacenamiento de datos e Inteligencia de negocios).
 Divida las jerarquías (push-down): Para reducir conjuntos de consulta,
donde las tablas de padres se dividen en múltiples tablas secundarias por
tipo. Por ejemplo, crear tablas de cliente que contienen cada uno un tipo
de cliente diferente, tales como cheques, hipotecas, inversiones, etc.
 División vertical: Para reducir conjuntos de consultas, cree tablas que
contienen sub conjunto de columnas. Por ejemplo, dividir 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 son comúnmente incluidos en las consultas o son poco
frecuentes (para mejorar el rendimiento mesa de exploración).
 División horizontal: Para reducir conjuntos de consultas, crear sub-
conjuntos de tablas utilizando el valor de una columna como el
diferenciador. Por ejemplo, crear tablas de clientes regionales que
contienen sólo los clientes en una región específica.
 Combinar y unir tablas: Para reducir uniones donde dos tablas se
combinan en un número significativo de consultas, considere la creación
de una tabla que ya cuenta con el conjunto de resultados de la
combinación de ambas tablas.
 Repetir las columnas en una fila: Para reducir el recuento de filas o
para permitir comparaciones entre las filas, crear una tabla con filas
repetidas. Por ejemplo, en lugar de 12 filas por 12 meses, tienen 12
columnas, una para cada mes.
  Obtener datos a partir de datos almacenados: Para reducir costo de
cálculo en tiempo de consulta, especialmente cálculos que requieren
datos de varias tablas, pre-calcular columnas y almacenar los resultados
en una tabla ya sea una nueva tabla o uno de las que participa en el
cálculo.
 Crear copias de informes: Para mejorar el rendimiento informe, cree
una tabla que contiene todos los elementos necesarios para la
presentación de informes ya calculado y unidos y actualícelos
periódicamente.
 Duplicar (espejos): Para mejorar el rendimiento cuando se utilizan con
frecuencia ciertos conjuntos de datos y que se encuentran
frecuentemente en disputa, crear versiones duplicadas para grupos de
usuarios independientes, o para la carga vs. la consulta.
[Link].3 Documentación de diseño de base de datos física
El documento de diseño de base de datos física se orienta a la ejecución y
mantenimiento. Se revisa para detectar y corregir los errores en el diseño antes
de crear o actualizar la base de datos. Se modifica para facilitar la aplicación
de las futuras iteraciones del diseño. Un documento de diseño de base de datos
física consta de los siguientes componentes:
 Una descripción introductoria de la función de negocio del diseño de
bases de datos; por ejemplo, ¿qué aspecto o subconjunto de los datos de
negocio abarca este diseño de base de datos?
 Un modelo gráfico del diseño, realizado en formato ER para un diseño
relacional, o un UML para un diseño orientado a objetos.
 Declaraciones de especificación del lenguaje de base de datos. En
Lenguaje de consultas estructurado (SQL), están las especificaciones de
Lenguaje de Definición de Datos (DDL) para todos los objetos de base
de datos (tabla espacios, tablas, índices, espacios de índices, vistas,
secuencias, etc. y XML espacio de nombres).
 Documentación de los metadatos técnicos, incluyendo el tipo de datos,
la longitud de dominio, el origen y uso de cada columna y la estructura
de las claves y los índices relativos a cada tabla.
 Los casos de uso o datos de ejemplo, que muestra cómo se verán los
datos reales.
 Descripciones cortas, según sea necesario, para explicar:
o La arquitectura de base de datos y la tecnología
elegidas y el motivo por la que fueron elegidas.
o Limitaciones que afectaron a la selección del DBMS,
incluyendo limitaciones de costos, limitaciones de la
 política, las limitaciones de rendimiento, limitaciones
de fiabilidad y escalabilidad, restricciones de seguridad,
las limitaciones de aplicación, los volúmenes de datos
esperados, etc.
o El proceso de diseño de base de datos, incluyendo los
métodos y herramientas utilizadas.
o Las diferencias entre el diseño físico de bases de
datos y el modelo de datos lógicos y las razones de
estas diferencias.
o El mecanismo de actualización elegido para la base
de datos y su aplicación.
o Los requisitos de seguridad para la base de datos y su
aplicación.
o El acuerdo de nivel de servicio (SLA) para la base de
datos y su aplicación.
o Solicitudes de los usuarios y / o de aplicación para la
base de datos y su aplicación.
[Link] Diseño de Productos de Información
Mientras que el diseño de bases de datos es el objetivo principal de desarrollo
de datos, los profesionales de datos también deben participar en el diseño de
los entregables de relacionados con los datos.
Los analistas de datos pueden ayudar a los diseñadores y desarrolladores de
software en el diseño de productos de información, incluidas las pantallas e
informes, para satisfacer las necesidades de datos empresariales. Los analistas
de datos deben garantizar un uso coherente de la terminología de datos
empresariales y deben garantizar que los formatos de presentación agregan
contexto apropiado a los datos de los productores de datos y los usuarios de la
información.
El DBA a menudo ayuda en el desarrollo de aplicaciones haciendo que los
datos estén disponibles más fácilmente, en una forma más útil, para los
usuarios de negocios y gerentes. Existen nuevas tecnologías para este fin y el
DBA debe estar familiarizado con ellos:
 Servicios de informes: Los servicios de informes ofrecen a los usuarios
de negocio la capacidad de ejecutar tanto informes enlatados como ad-
hoc, y han hecho que los datos estén disponibles de diferentes maneras,
como ser entregado (publicado) vía e-mail o RSS, accesible a través de
navegador web o portal, exportados a una hoja de Excel, entre otros.
 Servicios de análisis: Los servicios de análisis ofrecen a los usuarios
de negocio la capacidad de “cortar y extraer” datos a través de múltiples
dimensiones de negocio, como para analizar las tendencias de ventas
para los productos o categorías de productos a través de múltiples áreas
geográficas y / o fechas / horas. Esto también incluye “análisis
predictivo”, que es el análisis de datos para identificar las tendencias
futuras y posibles de oportunidades de negocio.
 Tablero de control: Un tablero de control es un tipo de interfaz de
usuario diseñada para mostrar una amplia gama de análisis de
indicadores, tales como tablas y gráficos, de manera eficiente. El usuario
puede “profundizar” a través de estos indicadores para ver los datos a
mayor nivel de detalle.
 Cuadros de Mando: Un cuadro de mando es un tipo especial de
visualización de gráficos que indica las puntuaciones o evaluaciones
calculadas de rendimiento. Las métricas a menudo tienen un valor real
(la medida), un objetivo o previsión (la línea de base), una puntuación
(medida de comparación con el valor base) y un indicador (una
representación visual de lo favorable o desfavorable del resultado que
puede ser).
 Portales: Los portales son interfaces web que presentan enlaces a
múltiples aplicaciones y fuentes de información sobre una única, y bien
diseñada, página web de fácil acceso. Los portales proporcionan un
punto de encuentro de un gran número de diversos usuarios, con
diferentes necesidades de información y la creación de una
“comunidad”, basada en intereses comunes. Los portales ofrecen a los
usuarios la posibilidad de compartir documentos, buscar a través de las
bibliotecas de documentos, mantener conversaciones y colaborar en
proyectos.
 Entrega de XML: Para habilitar el uso eficaz de XML dentro de las
bases de datos y aplicaciones, a menudo es necesario crear definiciones
de esquema. Estas definiciones validan documentos XML,
transformaciones XML (utilizando XSLT para convertir XML a HTML,
o alguna otra forma de presentación) y objetos de base de datos. Los
objetos de base de datos que necesitan validación incluyen vistas,
procedimientos almacenados y funciones que se pueden buscar a través
de documentos XML, convertir los datos XML a la forma relacional (o
viceversa) y combinar datos relacionales y datos XML.
 Automatización de procesos empresariales: Utilizar los datos
integrados de múltiples bases de datos como entrada al software para la
automatización de procesos de negocio que coordina múltiples procesos
de negocio a través de distintas plataformas.
  Integración de Aplicaciones: Del mismo modo, la integración de datos
(junto con sus componentes básicos, de transformación de datos y de
limpieza) es un componente clave de la integración de aplicaciones
empresariales de software (EAI), permitiendo a los datos pasar
fácilmente de aplicación a aplicación a través de las plataformas
dispares.
La participación del DBA en el desarrollo de estos productos puede incluir el
análisis de datos, la creación de estructuras de datos (tales como esquemas
XML, cubos OLAP, o data marts) y objetos de base de apoyo a estos
productos, lo que permite el acceso a los datos y ayuda con la integración y la
entrega de datos.
El DBA puede ayudar a los desarrolladores de software mediante la creación y
el mantenimiento de los estados de acceso de base de datos. En SQL, estas
declaraciones se conocen como Lenguaje de Manipulación de Datos (DML) e
incluyen SELECT, INSERT, UPDATE y DELETE. Los DBAs a menudo
revisan estas declaraciones y recomiendan enfoques alternativos y
modificaciones de optimización del rendimiento.
El DBA puede colaborar con los diseñadores y desarrolladores de software en
el diseño de servicios de datos de la capa de acceso en una arquitectura
orientada a servicios (SOA). Los servicios de acceso a datos estandarizan el
acceso a datos y aíslan a los programas de los cambios de base de datos.
[Link] Servicios de acceso de diseño de datos
Será a menudo necesario (y deseable) acceder a los datos en bases de datos
remotas y combinar esos datos con los datos en la base de datos locales.
Existen varios mecanismos para hacer esto y el DBA debe estar familiarizado
con las fortalezas y debilidades de cada uno. Algunos de los métodos más
comunes de acceso y reutilización de datos remotos son los siguientes:
 Las conexiones de tipo “servidor vinculado”: Algunos DBMS
permiten definir los servidores de bases de datos remotos como
“servidores vinculados” y acceder a ellos a través de una conexión
ODBC u OLE / DB. Este enfoque tiene la ventaja de ser rápido, fácil y
barato; Sin embargo, hay algunas consideraciones a tener en cuenta:
o Estas conexiones tienen una funcionalidad limitada;
generalmente se limita a la ejecución de una consulta no
modificable definida como una cadena literal, o un
procedimiento almacenado.
o Pueden presentar problemas de seguridad. No utilice
los identificadores de usuario y contraseñas codificadas
 escritas en la definición de este tipo de conexiones y
restringa los permisos en el servidor de destino a un
subconjunto de sólo lectura de sólo los datos
requeridos.
o No se escalan bien. Úselos sólo por cantidades
pequeñas de datos).
o Son sincrónicas, lo que requiere que el
procedimiento de llamada tenga que esperar a que todos
los datos sean recuperados.
o Dependen de la calidad de la ODBC suministrado
por el proveedor o los controladores OLE / DB (que a
veces es abismal).
Sin embargo, este método tiene una gran ventaja: es fácilmente implementable
en la base de datos, lo que permite el acceso a datos remotos de vistas,
disparadores, funciones y procedimientos almacenados en la base de datos.
 Servicios Web SOA: encapsula el acceso de datos a distancia en forma
de servicios web y los llaman desde las aplicaciones. Se implementan de
forma síncrona o asíncrona, en función de los requerimientos de la
aplicación. Este enfoque aumenta en gran medida la reutilización de
datos en las aplicaciones y en general es eficiente y escala bastante bien.
Sin embargo, hay un par de inconvenientes:
o Los servicios web son más difíciles y más costosas
para escribir, probar e implementar.
o La organización corre el riesgo de crear un “SOA
Nightmare” de numerosos servicios web punto a punto
de aplicación específica no reutilizables, los cuales
deben mantenerse en respuesta a los cambios de
esquemas y ubicaciones de bases de datos.
o Es difícil para los objetos de base consumir servicios
web. Por lo general, deben ser consumidos por las
aplicaciones. Algunos de los DBMS más nuevas
permiten encapsular clases de la aplicación como
procedimientos almacenados o funciones; Sin embargo,
este método no funcionará para las vistas.
 Intermediarios de mensajes: Algunos DBMS (por ejemplo, Microsoft
SQL Server 2005) permiten implementar los servicios de mensajería en
la base de datos. Un procedimiento almacenado o función en una base
de datos puede enviar un mensaje resultante de la ejecución de una
consulta, procedimiento almacenado o función en otra base de datos,
con los resultados devueltos de forma asíncrona al procedimiento de
llamada. Este enfoque es relativamente fácil de implementar, fiable,
escalable y funciona bien. Sin embargo, sólo funciona con instancias del
mismo DBMS.
 Clases de acceso a datos: Escribir clases de la aplicación que utilizan
ODBC o conexiones OLE / DB para acceder a datos en servidores
dispares, remotos y lo ponen a disposición de aplicaciones. En el
entorno .NET, estos datos se puede almacenar internamente como un
objeto conjunto de datos [Link] (una especie de base de datos en
memoria) para la facilidad de acceso y un mejor rendimiento. De forma
similar existe otro proveedores y tecnología de código abierto para
aplicaciones Unix / Linux y Java.
 ETL: En los casos en que no sea tecnológicamente posible acceder a
los datos en su origen, o donde las consideraciones de rendimiento
hacen que este insostenible, varios DBMS y herramientas ETL de
terceros puede reducir esas diferencias. Estas herramientas extraen datos
de la fuente, lo transforman en caso necesario (por ejemplo,
cambiándolo de formato y limpiándolo) o bien se cargan en una tabla de
sólo lectura en la base de datos, o transmiten el conjunto de resultados al
procedimiento de llamada o a la aplicación. Ejecute un paquete ETL
DBMS desde un procedimiento almacenado o función y prográmelo
para que se ejecute en intervalos periódicos. Las principales desventajas
son que no se puede escalar o que no tiene buen rendimiento para un
gran número de registros y puede ser difícil y costoso de mantener en el
tiempo.
 Réplica: Otra opción para obtener datos de un entorno de base de datos
a otro es la replicación. La mayoría de los DBMS soportan algún tipo de
tecnología de replicación (por ejemplo, el espejo y el traspaso de
registros), aunque esta replicación requiere que los servidores de origen
y de destino sean las mismas DBMS. Para la replicación a través de
plataformas dispares o DBMS, son posibles soluciones más “caseras”.
Por ejemplo, un proceso por lotes en una plataforma puede extraer datos
a un archivo plano en el disco. El archivo se puede copiar (a través de
FTP o algún mecanismo similar) para el servidor de destino y luego
carga a través de otro proceso por lotes. El reto es hacerlo en el tiempo
correcto (es decir, asegurar que los datos llega al servidor de destino
antes de que sea necesario) y asegurarse que cualquier fallo en el
proceso de replicación sea detectado y reportado rápidamente. Tenga en
cuenta que si los datos replicados van a ser actualizados en el servidor
de destino (tratar de evitar esto si es posible!), un mecanismo seguro y
fiable se debe poner en lugar de replicar esos cambios de nuevo al
 servidor de origen, idealmente a través de algún tipo de proceso de
confirmación de dos fases.
 Co-locación: Como último recurso, puede ser necesario para ubicar las
bases de datos de origen y destino (o instancias DBMS) en el mismo
servidor de base de datos. Obviamente, esto no es una solución ideal ya
tightly-couples que herméticamente parejas las dos bases de datos. Se
debe utilizar sólo en situaciones donde los datos son similares en
significado negocio y uso y en donde los volúmenes de datos requerido
(o la frecuencia de acceso) se opone a cualquier otra solución.
Recuerde que el objetivo final es permitir la reutilización fácil y barata de los
datos en toda la empresa, evitar, siempre que sea posible, costosos esquemas
de replicación de datos y la prevención, siempre que sea posible, de datos
redundantes e inconsistentes.
[Link] Diseño de integración de datos
Una transacción de base de datos es una unidad atómica de trabajo
recuperable. Una transacción puede incluir varias instrucciones de bases de
datos. Una vez finalizados todos los pasos dentro de la transacción, un
COMMIT de base de datos se compromete a realizar todos los cambios juntos.
Hasta ese momento, los cambios se pueden revertir. Una transacción es
atómica, lo que significa “todo o nada”. Se llevan a cabo todas las
instrucciones, o ninguna. Los desarrolladores de aplicaciones definen las
transacciones de bases de datos determinando cuando hacer el COMMIT de
los cambios.
Un aspecto crítico de diseño de base de datos es la determinación de los
mecanismos de actualización adecuados. Siempre que varios usuarios pueden
actualizar tablas simultáneamente, hay que implementar algún mecanismo de
control de concurrencia para asegurarse de que dos usuarios no puedan
actualizar el mismo registro al mismo tiempo. Esto implica generalmente la
adición de un elemento de datos de tipo “marca de tiempo” o “fecha y hora”
para cada una de estas tablas, asegurándose de que se verifique el valor de este
campo antes de modificar el registro y actualice cada vez que se cambia el
registro.
Utilice el bloqueo para asegurar la integridad de los datos, permitiendo que
sólo un usuario pueda cambiar una fila de base de datos en cualquier
momento. El bloqueo de datos en los diferentes niveles, conocidos como
granularidad del bloqueo. Los DBAs determinan el nivel apropiado de
bloqueo para cada objeto de base de datos, tales como la columna, fila, página,
tabla, archivo o base de datos.
Los analistas de datos y especialistas en integración de datos también definen
las asignaciones de origen-destino y los diseños de transformación de datos
para los programas de extracción, transformación y carga de datos (ETL) y
otras tecnologías para el continuo movimiento de datos, la limpieza y la
integración. El DBA puede colaborar en esta actividad de diseño.
Los analistas de datos, especialistas en integración de datos y administradores
de bases también diseñan programas y utilidades para la migración y
conversión de datos de las estructuras de datos antiguos a las nuevas
estructuras de datos.
Hay varios métodos disponibles, pero cualquier método elegido debe cumplir
los siguientes criterios:
1. Realizar todas las actualizaciones de una manera controlada. No
permitir la actualización directa, ad-hoc de la base de datos.
2. Administrar todas las actualizaciones relacionadas con un
proceso de negocio particular como una sola unidad de trabajo y/o bien
confirmar o retrotraer en forma completa la transacción conocida como
la integridad transaccional. No permita que se produzcan actualizaciones
parciales en la base de datos.
3. No permita que dos o más usuarios actualicen el mismo registro
al mismo tiempo, sin el conocimiento del otro, conocido como control
de concurrencia.
4. Interrumpir la transacción actual y hacer retroceder los errores
en la actualización, e informar inmediatamente el error en el proceso o
aplicación de llamada.
5. Restringir la capacidad de actualizar una tabla de base de datos
en particular a un conjunto de usuarios (contenida en una o más
funciones de usuario) autorizado para hacerlo.
6. Restringir cambios a un pequeño número de registros a la vez,
para evitar el bloqueo excesivo de tablas y “el colgado” de una
aplicación cuando se vuelva atrás una actualización grande.
Tenga en cuenta los siguientes posibles mecanismos de actualización:
 Procedimientos fundamentales de almacenamiento (FSP –
Fundamental Store Procedures): Cada FSP implementa una operación
(Insertar, Actualizar, Borrar, o Seleccionar) en un número limitado de
registros, generalmente designado por uno o más valores clave, para una
sola tabla de base de datos. Generar automáticamente FSPs, si se utiliza,
ya sea desde el modelo físico o desde el esquema de base de datos. Esto
reduce en gran medida el tiempo requerido para implementar una base
 de datos y hace que sea más fácil cambiar el esquema en respuesta a los
nuevos requisitos.
 Capa de datos de aplicación: Escriba un componente de aplicación que
llame a procedimientos almacenados en la base de datos para realizar las
actualizaciones a través de múltiples tablas, o que las llamadas múltiples
o que llame a múltiples FSPs. Se recomiendan los procedimientos de
almacenamiento porque tienen mejor rendimiento ya que se ha pre-
compilado y pre-optimizado el código SQL. Son más seguros ya que los
usuarios o roles sólo designados pueden ejecutarlos y las tablas no se
abren hasta que ataque una inyección SQL. Son más fáciles de mantener
y los errores o problemas de rendimiento pueden ser fácilmente
detectados y corregidos.
 Actualización del conjunto de datos: Actualizar registros en un
conjunto de datos de aplicación o tabla de datos a través de un objeto
adaptador de datos, que puede, a su vez, asociarse con un conjunto de
procedimientos almacenados para realizar operaciones de inserción,
actualización, supresión y selección.
 Vistas actualizables: En algunos DBMS relacionales, las vistas se
pueden asociar con un conjunto “en lugar de” de disparadores que
pueden manejar las actualizaciones de las tablas subyacentes de una
manera controlada. Como con los FSPs, es preferible generar el código
de forma automatizada para reducir o eliminar el tiempo insumido en la
codificación, pruebas y mantenimiento.

5.2.5 Modelo de Datos y Diseño de Gestión de Calidad

Analistas y diseñadores de datos actúan como un intermediario entre los
consumidores de información (las personas con los requerimientos del
negocio para los datos) y los productores de datos que capturan los datos en
forma utilizable. Los profesionales de datos deben hacer malabares con los
requisitos de datos de negocios de los consumidores de información, incluidos
los ejecutivos y los requisitos de las aplicaciones de los productores de datos.
Los requisitos del sistema documentan requisitos de datos de aplicación en
forma de casos de uso, un modelo de clase de aplicación y acuerdos de nivel
de servicio (SLAs).
Los profesionales de datos también deben negociar entre los requerimientos a
corto plazo frente a los de largo plazo. Los consumidores de información
necesitan los datos de manera oportuna para cumplir con las obligaciones
comerciales a corto plazo y para aprovechar las oportunidades de negocios
actuales. Los equipos de proyecto del sistema de desarrollo deben cumplir con
las limitaciones de tiempo y presupuesto. Sin embargo, también deben cumplir
con los intereses a largo plazo de todas las partes interesadas, garantizando
que los datos de una organización residen en las estructuras de datos que son
seguros, recuperables, compartibles y reutilizables y que esta información es
tan correcta, oportuna, relevante y utilizable como posible. Por lo tanto, los
modelos de datos y diseños de bases de datos deben tener un equilibrio
razonable entre las necesidades a corto plazo y las necesidades a largo plazo
de la empresa.
[Link] Desarrollar modelado de datos y normas de diseño
Los estándares de modelado de datos y diseño de bases de datos sirven como
principios básicos para responder eficazmente a las necesidades de
información de negocios, se ajustan a la arquitectura de datos y garantizar la
calidad de los datos. Los arquitectos de datos, analistas de datos y
administradores de bases de datos deben desarrollar conjuntamente estas
normas. Ellos deben complementar y no entrar en conflicto con los estándares
de TI relacionados.
Publicar modelo de datos y estándares de nomenclatura de base de datos para
cada tipo de modelado de objetos y objetos de base de datos. Las normas de
denominación son particularmente importantes para las entidades, tablas,
atributos, llaves, vistas e índices. Los nombres deben ser únicos y lo más
descriptivos posible.
Los nombres lógicos deben ser significativos para los usuarios de negocios
utilizando al máximo palabras completas y evitando todo pero si usar las
abreviaturas más familiares. Los nombres físicos deben ajustarse a la longitud
máxima permitida por el DBMS y utilizar abreviaturas cuando sea necesario.
Mientras que los nombres lógicos utilizan espacios en blanco como
separadores entre palabras, los nombres físicos suelen utilizar guiones como
separadores de palabras.
Los estándares de nomenclatura deben minimizar los cambios de nombre a
través de ambientes. Los nombres no deben reflejar su entorno específico,
como prueba, control de calidad, o producción. Las clases de palabras pueden
ser útiles para distinguir los atributos de las entidades y los nombres de las
columnas de nombres de tabla. También pueden mostrar qué atributos y
columnas son cuantitativas y no cualitativas, lo cual puede ser importante
cuando se analiza el contenido de esas columnas.
Las normas del modelado de datos y el diseño de bases de datos deben incluir:
 Una lista y descripción de los estándares de modelado de datos y
diseño de bases de datos entregados.
  Una lista de nombres estándar, abreviaturas aceptables y las reglas de
abreviación de palabras poco comunes, que se aplican a todos los
objetos del modelo de datos.
 Una lista de los formatos de nomenclatura estándar para todos los
objetos del modelo de datos, incluidos los atributos y de clase columna
de palabras.
 Una lista y descripción de los métodos estándar para la creación y el
mantenimiento de estas prestaciones.
 Una lista y descripción de roles y responsabilidades del modelado de
datos y diseño de bases de datos.
 Una lista y descripción de todas las propiedades de metadatos
capturados en el modelado de datos y diseño de bases de datos,
incluyendo tanto los metadatos técnicos de negocio de metadatos y con
las directrices que definen las expectativas y exigencias de calidad de
metadatos.
 Directrices para el uso de las herramientas de modelado de datos.
 Directrices para la preparación y liderazgo de revisiones de diseño.
[Link] Revisión del modelo de datos y calidad de diseño de base
de datos
Los equipos de proyecto deben llevar a cabo los requisitos y las revisiones de
diseño según sea el caso. Estas revisiones deben incluir una revisión
conceptual del modelo de datos, una revisión lógica del modelo de datos y una
revisión del diseño de base de datos física.
Las revisiones de diseño deben llevarse a cabo con un grupo de expertos en la
materia que representan diferentes orígenes, habilidades, expectativas y
opiniones. Los participantes deben ser capaces de discutir diferentes puntos de
vista y llegar a un consenso de grupo sin conflicto personal ya que todos los
participantes comparten el objetivo común de promover la mejor práctica,
mejor rendimiento y el diseño más utilizable. Realizar cada revisión del diseño
con un líder que facilite la reunión. El líder crea y sigue una agenda, asegura
que toda la documentación requerida esté disponible y se distribuya, solicita
aportes de todos los participantes, mantiene el orden y mantiene la reunión en
movimiento y resume las conclusiones que consensua el grupo. Muchas
revisiones de diseño también utilizan un escrito para capturar puntos de
discusión.
[Link].1 Revisiones de modelo de datos lógicos y conceptuales.
Las revisiones de modelo de datos conceptuales y modelos de datos de diseño
lógicos deben asegurarse de que:
 1. Los requisitos de datos de negocios están totalmente capturados
y claramente expresado en el modelo, incluyendo las reglas de negocio
que regulan las relaciones entre entidades.
2. Nombres de empresas (lógicas) y definiciones de negocio para
las entidades y atributos (semántica de negocios) son claros, prácticos,
coherentes y complementarias. El mismo término debe ser utilizado en
ambos nombres y descripciones.
3. Los estándares de modelado de datos, incluyendo estándares de
nomenclatura, se han seguido.
4. Se han validado los modelos de datos conceptuales y lógicos.
[Link].2 Revisión de diseño de base de datos físicos
Las revisiones diseños de base de datos deben asegurarse que:
1. El diseño cumple con los negocios, la tecnología, el uso y los
requisitos de rendimiento.
2. Los estándares de diseño de base de datos, incluidas las normas
de nomenclatura y abreviación, se han seguido.
3. La disponibilidad, recuperación, archivo y procedimientos de
purga se definen de acuerdo a las normas.
4. Las expectativas y los requisitos de calidad de metadatos que se
cumplan a fin de actualizar adecuadamente cualquier depósito de
metadatos.
5. El modelo de datos físico ha sido validado.
Todas las partes interesadas, incluido el grupo de DBA, el analista de datos /
arquitecto, los propietarios de los datos de negocio y / o administradores, los
desarrolladores de aplicaciones y los jefes de proyecto, deben revisar y
aprobar el documento de diseño de base de datos físico. El documento
completo de diseño debe estar listo como parte de la cifra de negocios de
producción de la base de datos.
[Link].3 Validación de Modelo de Datos
Validar modelos de datos con los estándares de modelado, los requerimientos
del negocio y los requisitos de las bases de datos. Aquí hay algunas preguntas
ejemplo de validación:
 ¿Coincide el modelo de estándares de modelado aplicables? ¿Utiliza el
modelo de términos del diccionario de datos estándar? ¿Utiliza el
modelo de dominios estándar? ¿Utiliza modelos de palabra sufijos de
clase en todas las columnas aplicables? ¿El modelo incluye una
 descripción de todos los objetos y las relaciones? ¿Utiliza abreviaturas
estándar el modelo donde aplique?
 ¿El modelo coincide con los requerimientos del negocio? ¿El modelo
contiene todos los elementos de datos pertinentes? ¿Puede ejecutar las
transacciones requeridas contra la base de datos? ¿Puede recuperar el
contenido de transacción correctamente? ¿Puede ejecutar cualquier
consulta requerida contra el modelo?
 ¿El modelo coincide con los requisitos de las bases de datos? ¿No hay
objetos que se nombran como palabras reservadas con bases de datos?
¿Todos los objetos tienen nombres únicos? ¿El modelo asigna a los
propietarios de todos los objetos?
[Link] Gestionar versiones de modelado de datos e integración
Los modelos de datos y otras especificaciones de diseño requieren un control
cuidadoso de cambio, al igual que las especificaciones de requisitos y demás
prestaciones del SDLC. Nota cada cambio a un modelo de datos para
preservar de donde vienen los cambios en el tiempo. Si un cambio implica el
modelo lógico, tales como el requisito de datos de negocios nuevos o
modificados, el analista de datos o arquitecto deben revisar y aprobar el
cambio.
Cada cambio debe tener en cuenta:
 ¿Por qué el proyecto o situación requiere el cambio?
 ¿Qué y cómo cambió el objeto (s), incluyendo las tablas en al que se
tiene columnas agregadas, modificadas o eliminadas, etc?
 ¿Cuándo se aprobó el cambio y cuando se hizo el cambio en el
modelo? Esto no es necesariamente cuando se implementó el cambio en
un sistema.
 ¿Quién hizo el cambio?
 ¿Donde se hizo el cambio; para cuales modelos?
Se pueden hacer cambios a múltiples partes de los modelos de la empresa
simultáneamente como parte del proceso normal. Es importante integrar los
cambios en una parte del modelo nuevo en el modelo de empresa,
especialmente el modelo lógico de la empresa, para evitar errores en los datos
y bases de datos durante el desarrollo futuro.
Algunas herramientas de modelado de datos incluyen depósitos que
proporcionan modelo de datos de versiones y funcionalidad de integración. De
lo contrario, preservar los modelos de datos de las exportaciones de DDL o
archivos XML, comprobando en y fuera de un sistema de gestión de código
fuente estándar (SCM) al igual que el código de aplicación.
5.2.6 Implementación de datos
Implementación de Datos consiste en actividades de gestión de datos que
apoyan la construcción del sistema, pruebas y despliegue, incluyendo:
 Aplicación de base de datos y la gestión de cambios en los entornos de
desarrollo y pruebas.
 La creación de datos de prueba, incluyendo cualquier procedimiento de
seguridad, como la ofuscación.
 Desarrollo de programas de migración de datos y de conversión, tanto
para el desarrollo del proyecto a través de la SDLC y para situaciones de
negocios como consolidaciones o desinversiones.
 Validación de los requisitos de calidad de datos.
 Creación y entrega de la formación de usuarios.
 Contribución al desarrollo de la documentación eficaz.
Después del diseño, el DBA es responsable de la aplicación de las estructuras
de datos diseñadas en los entornos de desarrollo y pruebas. Estas estructuras
incluyen tablas de bases de datos o archivos, vistas, procedimientos
almacenamientos y funciones, cubos de datos OLAP, esquemas XSLT y otros
objetos similares. El DBA es responsable del control de cambio del entorno de
base de desarrollo y su configuración. Procedimientos de control de cambios
para entornos de desarrollo y de prueba deben ser similares o los mismos que
los utilizados para controlar los entornos de producción. El DBA debe
administrar cambios de configuración en las especificaciones de diseño de
base de datos (DDL) archivos utilizando las mismas herramientas y prácticas
de gestión de cambios y configuración utilizados para otras prestaciones del
sistema de información.
[Link] Implementar el Desarrollo / probar los cambios de base de
datos
Como se requieren cambios en la base de datos durante el curso de desarrollo
de aplicaciones, los DBA los instrumentan o supervisan. Estos cambios
generalmente provienen del desarrollador. La implementación ocurre
dependiendo de las funciones y responsabilidades:
 Los desarrolladores pueden tener la capacidad de crear y actualización
de base de datos de objetos directamente, tales como vistas, funciones y
procedimientos almacenados y luego notifican a los DBAs y
modeladores de datos para la revisión y actualización del modelo de
datos.
  El equipo de desarrollo puede tener su propio “desarrollador DBA”
que se le da permiso para hacer cambios de esquema, con la condición
de que estos cambios sean revisados con el DBA y modelador de datos.
 Los desarrolladores pueden trabajar con los modeladores de datos, que
hacen el cambio en la herramienta de modelado de datos y luego
generan el “cambio DDL” para los administradores de base de datos lo
revisen y lo pongan en práctica.
 Los desarrolladores pueden trabajar con los modeladores de datos, que
de forma interactiva “empujan” los cambios en el entorno de desarrollo,
utilizando la funcionalidad de la herramienta de modelado de datos,
después de la revisión y aprobación por parte de los administradores de
bases de datos.
Si se utiliza un método de desarrollo iterativo (por ejemplo, Desarrollo Ágil),
entonces algunos de los trabajos de revisión y aprobación de los cambios y la
actualización de los modelos lógicos y físicos, puede ser necesario hacerlos de
forma asíncrona. Considere dar aprobaciones verbalmente para que el
desarrollo pueda continuar sin interrupciones indebidas y hacer la
actualización de los modelos como una tarea de continuación. Sin embargo,
tenga cuidado para asegurarse de que la base de datos no quede “fuera de
sincronización” con el modelo lógico. Implemente los requerimientos
específicos de la aplicación de base de datos tanto como sea posible, usando
vistas, procedimientos almacenados, funciones y otras formas de
virtualización de datos.
El DBA debe vigilar cuidadosamente todo el código de base de datos para
asegurarse que está escrito con las mismas normas que el código de
aplicación. Todo el código de base de datos debe estar bien documentado,
comprobable (idealmente, que contienen incorporado en el código de
diagnóstico que puede ser activado a través de un parámetro pasado),
comprensible, de acuerdo con la normas acordadas y de fácil mantenimiento.
La DBA también debe identificar, tan pronto como sea posible las prácticas de
codificación SQL, que podrían conducir a errores o problemas de pobre
rendimiento y llevarlos a la atención de los desarrolladores antes que múltiples
procedimientos almacenados o funciones sean replicados con código SQL
pobre. Prestar un poco más de atención al inicio de un proyecto puede salvar a
todos de gran cantidad de problemas más adelante.
[Link] Crear y mantener los datos de prueba
Los DBA, desarrolladores y probadores de software pueden colaborar para
poblar las bases de datos en el entorno de desarrollo con datos de prueba. Ya
sea generando datos de prueba o extrayendo un subconjunto representativo de
datos de producción. Observe estrictamente los requisitos y prácticas de
privacidad y confidencialidad de los datos de prueba. Borrar los datos de
prueba obsoletos, inutilizables y que ya no se necesitan.
La DBA también puede ayudar a los desarrolladores a la creación de scripts de
SQL y los “paquetes” de integración de datos, tales como los paquetes DTS o
SSIS, que sirve para crear y mantener los datos de prueba. Por lo general, el
principal responsable de este trabajo es el equipo de desarrollo, pero muchas
veces ellos necesitan de la experiencia del DBA. Esta es otra manera de que
los administradores de bases pueden agregar valor a los esfuerzos de
desarrollo.
[Link] Migrar y convertir los datos
Un componente clave de muchos proyectos es la migración de datos
heredados a un nuevo entorno de base de datos, incluyendo cualquier limpieza
de datos y cambio de formato necesario. Este es un esfuerzo significativo.
Requieren el tiempo y el costo no debe ser (pero probablemente serán)
subestimada. Se requerirá la colaboración del arquitecto/analista de dato(s)
familiarizado con el modelo de datos heredados (s) y el modelo de datos de
destino, el DBA, los usuarios de negocio y los desarrolladores familiarizados
con la aplicación (s) de legado. Según el lugar donde se almacenan los legados
de datos, este esfuerzo puede implicar el uso de muchas tecnologías
diferentes, incluyendo SQL, COBOL, scripting de Unix, paquetes de
integración de DBMS, como DTS o SSIS, DBMS no relacionales,
aplicaciones ETL de terceros, integración de datos servicios web, FTP, RPC,
ODBC, OLE / DB y así sucesivamente. Esfuerzos de migración de datos
pueden consumir fácilmente miles de horas de esfuerzo.
[Link] Construir y probar información de productos
Los profesionales de datos, incluyendo el DBA, debe colaborar con los
desarrolladores de software en el desarrollo y pruebas de productos de
información creados por el sistema, incluyendo:
 La implementación de mecanismos para integrar datos de múltiples
fuentes, junto con los metadatos adecuados para garantizar una
integración significativa de los datos.
 La implementación de mecanismos para la presentación de informes y
el análisis de los datos, incluidos en línea y notificación en línea,
consultas ad-hoc, cuadros de mando de BI, OLAP, portales y similares.
 La implementación de mecanismos para la replicación de los datos, si
la latencia de la red u otras preocupaciones hacen que sea poco práctico
para dar servicio a todos los usuarios de una sola fuente de datos.
Los desarrolladores de software son responsables de los programas de
codificación y pruebas, incluidas las llamadas de acceso a base de datos. Los
desarrolladores de software también son responsables de la creación, prueba y
mantenimiento de productos de información, incluidas las pantallas e
informes. Las pruebas incluyen unidad, integración y pruebas de rendimiento.
[Link] Construir y servicios de acceso de datos de prueba
Los DBAs son responsables del desarrollo de servicios de acceso a datos. El
DBA colabora con los desarrolladores de software en el desarrollo, las pruebas
y la ejecución de los servicios de acceso de datos, primero para los entornos
de desarrollo y pruebas y más tarde para la implementación en producción.
Los requisitos de datos deben incluir reglas de negocio para guiar la
implementación de los servicios de acceso de datos, colaborando con los
desarrolladores de software. Administradores de datos de negocios y otros
expertos en la materia (PYME) deben validar la correcta aplicación de los
requisitos de acceso a datos y el rendimiento a través de pruebas de aceptación
del usuario.
[Link] Construir y servicios de integración de datos de prueba
Los especialistas en integración de datos son responsables de desarrollar los
programas de ETL y la tecnología para la integración de datos, así como la
migración de datos y la conversión de las estructuras de datos antiguos en
nuevas estructuras. El DBA colabora con los desarrolladores de software en el
desarrollo, las pruebas y la ejecución de los programas y procedimientos de
migración de datos y conversión, primero para los datos de prueba y
desarrollo y más tarde para la implementación en producción.
Los requisitos de datos deben incluir reglas de negocio para la calidad de
datos para guiar la implementación de aplicaciones y bases de datos editando
restricciones de integridad referencial. Los administradores de datos de
negocios y otros expertos en la materia (SME – Subjetct Matter Experts)
deben validar la correcta aplicación de los requisitos de datos a través de
pruebas de aceptación del usuario.
[Link] Validación de Requerimientos de información
Las responsabilidades de los profesionales de datos dentro del SDLC no
terminan con el diseño. Continúan por interactuar como parte de los equipos
de proyecto para el desarrollo del sistema a través de la implementación de
estos diseños. Los administradores de bases de datos son particularmente
activas en estas etapas SDLC. Los administradores de datos de negocios
también pueden seguir participando después de análisis y diseño, o un equipo
independiente de control de calidad independiente puede realizar el proceso de
prueba. El trabajo principal consistirá en probar y la validar que la solución
cumple con los requisitos, pero también en la planificación de la
implementación, el desarrollo de capacitación y la documentación.
En cualquier proyecto de desarrollo de aplicaciones, especialmente los que
usan métodos iterativos (“Agile”), los requerimientos de datos (y base de
datos) pueden cambiar abruptamente, en respuesta a los cambios y nuevos
requerimientos del negocio, invalidando las hipótesis con respecto a los datos,
o re-priorización de los requisitos existentes. El modelador de datos puede
servir de intermediario entre los desarrolladores y el analista de datos /
arquitecto, revisando los cambios adicionales en los requisitos de datos de
negocios. El modelador de datos también los reflejará adecuadamente en los
modelos de datos lógicos y físicos. El DBA implementará cualquier cambio en
la manera más eficaz en la base de datos. El DBA entonces trabaja con los
desarrolladores para probar la implementación de los requisitos de datos y
asegurarse de que los requisitos de las aplicaciones están satisfechos.
[Link] Preparación la implementación de datos
Mientras que los administradores de bases de datos se resuelven las cuestiones
de aplicación y pruebas técnicas, los analistas de datos pueden aprovechar el
conocimiento del negocio capturado en el modelado de datos para definir un
lenguaje claro y consistente para la capacitación de usuarios y documentación.
Negocios conceptos, terminología, definiciones y reglas representados en los
modelos de datos son una parte importante de la formación de usuarios de
aplicaciones, incluso si los modelos de datos en sí no son útiles como
ilustraciones de enseñanza. Los administradores de datos que contribuyen
conocimiento del negocio en la definición de los modelos de datos y que son
responsables de la calidad de datos del sistema, a menudo son también
propietarios de los procesos y aplicaciones responsables de aceptación de
usuario tanto del sistema como de la capacitación y documentación
correspondiente. Utilice su nomenclatura coherentemente.
Los administradores de datos y analistas de datos deben participar en la
preparación de implementaciones, incluyendo el desarrollo y revisión de los
materiales de capacitación y documentación del sistema, sobre todo para
garantizar un uso coherente de la terminología de datos de negocio definido.
El personal de la mesa de ayuda también requiere orientación y capacitación
sobre cómo los usuarios del sistema deben acceder, manipular e interpretar los
datos apropiadamente.
El DBA es el principal responsable de la implementación de objetos nuevos y
modificados de base de datos en el entorno de producción (véase el capítulo 6
de Gestión de Operaciones de Datos). Los administradores de bases de datos
deben controlar cuidadosamente la instalación de nuevas bases de datos y los
cambios en las bases de datos existentes en el entorno de producción. Una vez
instalados, los administradores de datos de negocios y analistas de datos deben
supervisar el uso temprano del sistema para ver que los requisitos de datos de
negocios de la empresa se cumplen efectivamente.

5.3 Resumen
A continuación se resumen los principios básicos para la implementación del
desarrollo de datos en una organización, una tabla resumen de los roles de
cada actividad de desarrollo de datos y la organización y las cuestiones
culturales que puedan surgir durante el desarrollo de datos se resumen a
continuación.

5.3.1 Principios Rectores

La implementación de la función de desarrollo de datos en una
organización sigue nueve principios básicos:
1. Las actividades de desarrollo de datos son una parte integral del
ciclo de vida del desarrollo de software (SDLC).
2. El modelado de datos es una técnica esencial para la gestión
eficaz de los datos y el diseño del sistema.
3. El modelado de datos conceptual y lógico expresan los
requerimientos del negocio y de la aplicación, mientras que el modelado
de datos físicos representa diseño de la solución. El modelado de datos y
diseño de bases de datos definen las especificaciones de los
componentes de solución en detalle.
4. El modelado de datos y el diseño de bases de datos equilibra
compensaciones y necesidades.
5. Los profesionales de datos deben colaborar con otros miembros
del equipo del proyecto para diseñar productos de información y acceso
a los datos e interfaces de integración.
6. El modelado de datos y diseño de bases de datos deben seguir
los estándares documentados.
7. Las revisiones de diseño deben revisar todos los modelos de
datos y diseños, con el fin de garantizar que cumplan con los
requerimientos del negocio y igan las normas de diseño.
 8. Los modelos de datos representan valiosos recursos de
conocimiento (metadatos). Se deben manejar con cuidado y controlarlos
a través de la biblioteca, la configuración y gestión del cambio para
garantizar la calidad del modelo de datos y la disponibilidad.
9. Los administradores de bases de datos (DBAs) y otros
profesionales de datos juegan un papel importante en la construcción,
prueba y despliegue de bases de datos y sistemas de aplicación
relacionados.

5.3.2 Resumen del proceso de desarrollo de datos

El resumen del proceso para la función de desarrollo de datos se muestra en
la Tabla 5.1. Los entregables, roles responsables, roles que aprueban y roles
que contribuyen se muestran para cada actividad de la función de desarrollo de
datos. La tabla también se muestra en el Apéndice A9.
Actividades Entregables Roles de Roles de Roles de contribución
Responsabilidad aprobación

3.1.1 Analizar Requisito de Arquitectos de Administradores Administradores de datos, Otros

Requerimientos Información de datos, Analista de datos
de información Especificación de datos
(D) Declaraciones

3.1.2 Informes y Arquitectos de Administradores Administradores de datos, Otros

Desarrollar y diagramas de datos, Analista de datos,
mantener modelo de datos de datos Arquitectos de
modelos de conceptuales datos
datos
conceptuales
(D)

3.1.3 Informes y Arquitectos de Administradores Administradores de datos, Otros

Desarrollar y Diagramas de datos, Analista de datos,
mantener modelo de datos de datos, Arquitectos de
modelos de lógicos Modeladores de datos
datos lógicos datos
(D)

3.1.4 Informes de Arquitectos de DBAs, Desarrolladores de software

Desarrollar y diagramas de datos, Arquitectos de
mantener modelos de Modeladores de datos
modelos físicos datos físicos datos, DBAs
de datos (D)
Actividades Entregables Roles de Roles de Roles de contribución
Responsabilidad aprobación

3.2.1 Diseño Especificaciones DBAs, Arquitectos de Analista de datos, Modeladores

Bases de datos DDL, OLAP Arquitectos de datos, DBAs, Desarrolladores de software
físicos (D) Especificaciones aplicación, Arquitectos de
de Cubo, Desarrolladores aplicación
Esquemas XML de software

3.2.2 Diseños Pantallas de Desarrolladores Arquitectos de Analista de datos, DBAs

de productos de aplicación, de software aplicación
Información Reportes
(D)

3.2.3 Diseño de Especificaciones Desarrolladores Arquitectos de Analista de datos, DBAs

servicios de de diseño de de software, aplicación,
acceso de datos servicio de DBAs Arquitectos de
(D) acceso de datos datos

3.2.4 Diseño de Mapas de fuente Especialistas en DBAs, Analista de datos, Administrado

integración de a objetivo, Integración de Arquitectos de
datos (D) Especificaciones Datos, DBAs, datos,
de diseño ETL, Analista de datos Arquitectos de
Diseños de aplicación
conversión

3.3.1 Revisión Documento de Arquitectos de Ejecutivo DM, Administradores de datos, Arqu

del modelo de estándares de datos, Analista Consejo de Desarrolladores de software
datos y diseño modelado de de datos, gobierno de
de base de datos, Modeladores de datos
calidad (P) Documentos de datos, DBAs
normas de
diseño de base
de datos

3.3.2 Revisión Resultados de la Arquitectos de Ejecutivo DM, Arquitectos de aplicación, Desar

del modelo de revisión de datos, Analista Gerente de
datos y diseño diseño de datos, proyecto
de base de Modeladores de
calidad (C) datos, DBAs
Actividades Entregables Roles de Roles de Roles de contribución
Responsabilidad aprobación

3.3.3 Bibliotecas y Administradores Arquitectos de Analista de datos, DBAs

Administrar Contenidos de modelado de datos, Ejecutivo
datos Modelo Modelo de datos, DM
de versiones e Gestión Modeladores de
Integración (C) datos

3.4.1 Ambientes de DBAs Ejecutivo DM Arquitectos de datos, Analista d

Implementar el Desarrollo y Desarrolladores de software
Desarrollo y base de datos de
Cambios de prueba, Tablas
base de datos de de base de datos,
prueba (D) Otros objetos
DB

3.4.2 Crear y Base de datos de DBAs, Analista Arquitectos de Administradores de datos, Desar
mantener datos prueba, Datos de de datos, datos, software, Analista de datos
de prueba (D) prueba Desarrolladores Arquitectos de
de software, aplicación,
Analista de Administradores
pruebas de datos

3.4.3 Migrar y Emigrado y DBAs, Administradores Analista de datos

convertir los Construcción de Desarrolladores de datos,
datos (D) Datos de software Arquitectos de
datos

3.4.4 Construir Información de Desarrolladores Administradores DBAs,

e información productos: de software de datos, Analista de datos
de productos de Pantallas, Arquitectos de
prueba (D) Reportes aplicación,
Arquitectos de
datos

3.4.5 Construir Servicios de Desarrolladores Arquitectos de DBAs

y servicios de acceso de datos de software datos,
acceso de datos (interfaces) Arquitectos de
(D) aplicación
Actividades Entregables Roles de Roles de Roles de contribución
Responsabilidad aprobación

3.4.6 Construir Servicios de Especialistas en Administradores DBAs,

y servicios de integración de Integración de de datos, Analista de datos
integración de datos (ETL, etc.) Datos Arquitectos de
datos de prueba datos
(D)

3.4.7 Requisitos Administradores Administradores Analista de datos, Arquitectos d

Validación de validados, de datos, de datos
requerimientos liberación del Especialistas de
de información usuario prueba
(D)

3.4.8 Prepararse Entrenamiento Administradores Administradores Administradores de datos, Arqu

para la del usuario, de datos, de datos,
implementación Documentación Negocio SMEs, Arquitectos de
de datos (D) del usuario Especialista en datos
entrenamientos,
Analista de datos

Tabla 5.1 Resumen del proceso de desarrollo de datos

5.3.3 Cuestiones de organización y cultura

P1: ¿Cuál es el mayor problema con la entrega de datos?
R1: El problema con respecto a la entrega de datos organizacional y cultural
más importante es simplemente el reconocimiento de la necesidad de hacerlo
y aprovechar lo que ofrece la elaboración de datos. Muchas organizaciones se
centran en el desarrollo de aplicaciones, pasando por alto la importancia de los
datos en sí. Simplemente descubrir la importancia y utilidad de análisis de
datos y modelado de datos puede ser transformacional a una organización.
Tanto el negocio y TI comienzan a considerar el impacto de los datos al
considerar cambios en el sistema, a veces darse cuenta de que ya tienen datos
y funcionalidad similares en otra aplicación o que realmente no necesitan lo
que ellos pensaban que tenían o querían.
P2: ¿Cómo se empieza el desarrollo formal de datos?
R2: Con el fin de iniciar la transformación es necesario comenzar sistemas de
documentar desde un punto de vista de datos. Los flujos de datos, modelos de
datos y calidad de los datos se analizan todos los factores en esta
documentación. Comience con un sistema y mover a los sistemas que ya sea
dar o recibir datos directamente desde el primer sistema.
A continuación, dar a conocer la existencia de estos nuevos documentos.
Crear una versión principal de los documentos e implementar cambios a ellos
como parte del SDLC. Cuando un proyecto entra en producción, parte de la
versión de producción es la de distribuir los flujos de datos actualizados y
modelos de datos.
Una vez que se corra la voz, los analistas de datos y modeladores de datos
estarán muy ocupados tanto como para documentar sistemas adicionales y
ayudar a los ingenieros de software a utilizar estos nuevos documentos
durante el trabajo del proyecto. Plantilla adicional para ese equipo
probablemente será necesario.
Será un proceso iterativo obtener acceso a todos los sistemas a fin de
analizarlos. Sea persistente. El dinero ahorrado de reducida redundancia del
sistema, la reducción de la redundancia de almacenamiento de datos y un
desarrollo más eficiente puede ahorrar los millones de dólares a la
organización.
El último paso es cambiar la cultura de la organización, moviéndose y
referirse automáticamente a estos documentos durante requisitos y diseño de
proyectos como un procedimiento operativo estándar. Una vez que el
desarrollo de datos es parte de la cultura, la organización dedicada al
mantenimiento crecerá para adaptarse a las necesidades de la organización.

5.4 Lectura recomendada

Las referencias que figuran a continuación proporcionan lectura adicional que
soportan el material presentado en el capítulo 5. Estas lecturas recomendadas
también se incluyen en la bibliografía al final de la Guía.

5.4.1 Modelado de datos y diseño de bases de datos

Ambler, Scott. Agile Database Techniques: Effective Strategies for the Agile
Software Developer. Wiley & Sons, 2003. ISBN 0-471-20283-5.
Ambler, Scott W. and Pramodkumar J. Sadalage. Refactoring Databases:
Evolutionary Database Design. Addison-Wesley, 2006. ISBN 0-321-29353-3.
Avison, David and Christine Cuthbertson. A Management Approach to
Database Applications. McGraw Hill, 2002. ISBN 0-077-09782-3.
Brackett, Michael H. Practical Data Design. Prentice Hall, 1990. ISBN 0-136-
90827-6.
Bruce, Thomas A. Designing Quality Databases with IDEF1X Information
Models. Dorset House, 1991. ISBN 10:0932633188. 584 paginas.
Carlis, John and Joseph Maguire. Mastering Data Modeling - A User-Driven
Approach. Addison Wesley, 2000. ISBN 0-201-70045-X.
Date, C. J. An Introduction to Database Systems, 8  Edition. Addison-Wesley,
th

2003. ISBN 0-321-19784-4.

Date, C. J. and Hugh Darwen. Databases, Types and the Relational Model:
The Third Manifesto, 3  Edition. Addison Wesley, 2006. ISBN 0-321-39942-
rd

0.
DeAngelis, Carla. Data Modeling with Erwin. Indiana: Sams Publishing,
2000. ISBN 0-672-31868-7.
Dorsey, Paul. Enterprise Data Modeling Using UML. McGraw-Hill Osborne
Media, 2007. ISBN 0-072-26374-1.
Fleming, Candace C. and Barbara Von Halle. The Handbook of Relational
Database Design. Addison Wesley, 1989. ISBN 0-201-11434-8.
Halpin, Terry. Information Modeling and Relational Databases: From
Conceptual Analysis to Logical Design. Morgan Kaufmann, 2001. ISBN 1-
558-60672-6.
Halpin, Terry, Ken Evans, Pat Hallock, and Bill McLean. Database Modeling
with Microsoft Visio for Enterprise Architects. Morgan Kaufmann, 2003.
ISBN 1-558-60919-9.
Harrington, Jan L. Relational Database Design Clearly Explained, 2  Edition.
nd

Morgan Kaufmann, 2002. ISBN 1-558-60820-6.

Hay, David C. Data Model Patterns: A Metadata Map. Morgan Kaufmann,
2006. ISBN 0-120-88798-3.
Hay, David C. Data Model Patterns: Conventions of Thought. Dorset House
Publishing, 1996. ISBN 0-932633-29-3.
Hay, David C. Requirements Analysis From Business Views to Architecture.
Prentice Hall, 2003. ISBN 0-120-28228-6.
Hernandez, Michael J. Database Design for Mere Mortals: A Hands-On Guide
to Relational Database Design, 2  Edition. Addison-Wesley, 2003. ISBN 0-
nd

201-75284-0.
Hoberman, Steve. The Data Modeler’s Workbench. Tools and Techniques for
Analysis and Design. John Wiley & Sons, 2001. ISBN 0-471-11175-9.
Hoberman, Steve. Data Modeling Made Simple: A Practical Guide for
Business & Information Technology Professionals. Technics Publications,
LLC, 2005. ISBN 0-977-14000-8.
Hoffer, Jeffrey A., Joey F.. George, and Joseph S. Valacich. Modern Systems
Analysis and Design, 4  Edition. Prentice Hall, 2004. ISBN 0-131-45461-7.
th

Krogstie, John, Terry Halpin, and Keng Siau, editors. Information Modeling

Methods and Methodologies: Advanced Topics in Database Research. Idea
Group Publishing, 2005. ISBN 1-591-40375-8.
Muller, Robert. J. Database Design for Smarties: Using UML for Data
Modeling. San Francisco, CA, USA, Morgan Kaufmann, 1999. ISBN 1-558-
60515-0.
Newton, Judith J. and Daniel Wahl,, editors. Manual For Data Administration.
Washington, DC: GPO, NIST Special Publications 500-208, 1993.
Pascal, Fabian. Practical Issues In Database Management: A Reference For
The Thinking Practitioner. Addison-Wesley, 2000. ISBN 0-201-48555-9.
Reingruber, Michael. C. and William W. Gregory. The Data Modeling
Handbook: A Best-Practice Approach to Building Quality Data Models. John
Wiley & Sons, 1994. ISBN 0-471-05290-6.
Riordan, Rebecca M. Designing Effective Database Systems. Addison-
Wesley, 2005. ISBN 0-321-20903-3.
Rob, Peter and Carlos Coronel. Database Systems: Design, Implementation,
and Management, 7  Edition. Course Technology, 2006. ISBN 1-418-83593-5.
th

Schmidt, Bob. Data Modeling for Information Professionals. Prentice Hall,

1999. ISBN 0-13-080450-9.
Silverston, Len. The Data Model Resource Book, Volume 1: A Library of
Universal Data Models for All Enterprises, 2  Edition, John Wiley & Sons,
nd

2001. ISBN 0-471-38023-7.

Silverston, Len. The Data Model Resource Book, Volume 2: A Library of
Data Models for Specific Industries, 2  Edition. John Wiley & Sons, 2001.
nd

ISBN 0-471-35348-5.
Simsion, Graeme C. and Graham C. Witt. Data Modeling Essentials, 3rd
Edition. Morgan Kaufmann, 2005. ISBN 0-126-44551-6.
Teorey, Toby , Sam Lightstone, and Tom Nadeau. Database Modeling and
Design, 4th Edition. Morgan Kaufmann, 2006. ISBN 1-558-60500-2.
Thalheim, Bernhard. Entity-Relationship Modeling: Foundations of Database
Technology. Springer, 2000. ISBN 3-540-65470-4.
Van der Lans, Rick F. Introduction to SQL: Mastering the Relational Database
Language, 4  Edition. Addison-Wesley, 2006. ISBN 0-321-30596-5.
th
Watson, Richard T. Data Management: Databases And Organization,
5  Edition. John Wiley & Sons, 2005. ISBN 0-471-71536-0.
th

5.4.2 Reglas de negocio

Chisholm, Malcolm. How to Build a Business Rules Engine: Extending
Application Functionality Through Metadata Engineering. Morgan Kaufmann,
2003. ISBN 1-558-60918-0.
Date, C. J., What Not How: The Business Rules Approach To Application
Development. Addison-Wesley, 2000. ISBN 0-201-70850-7.
Morgan, Tony. Business Rules and Information Systems: Aligning IT with
Business Goals. Addison-Wesley, 2002. ISBN 0-201-74391-4.
Ross, Ronald G. Business Rules Concepts, 2  Edition. Business Rule
nd

Solutions, 2005. ISBN 0-941-04906-X.

Ross, Ronald G. Principles of the Business Rule Approach. Addison-Wesley,
2003. ISBN 0-201-78893-4.
Von Halle, Barbara. Business Rules Applied: Building Better Systems Using
the Business Rules Approach. John Wiley & Sons, 2001. ISBN 0-471-41293-
7.

5.4.3 Ingeniería de la Información

Finkelstein, Clive. An Introduction to Information Engineering: From
Strategic Planning to Information Systems. Addison-Wesley, 1990. ISBN 0-
201-41654-9.
Finkelstein, Clive. Information Engineering: Strategic Systems Development.
Addison-Wesley, 1993. ASIN B000XUA41C.
Inmon, W. H. Advanced Topics in Information Engineering. John Wiley &
Sons - QED, 1989. ISBN 0-894-35269-5.
Inmon, W. H. Information Engineering For The Practitioner. Prentice-Hall
(Yourdon Press), 1988. ISBN 0-13-464579-0.
Martin, James. Information Engineering Book 1: Introduction. Prentice-Hall,
1989. ISBN 0-13-464462-X. Also see Book 2: Analysis and Design and Book
3: Design and Construction.

5.4.4 Desarrollo Ágil

Ambler, Scott. Agile Database Techniques: Effective Strategies for the Agile
Software Developer. Wiley & Sons, 2003. ISBN 0-471-20283-5.
5.4.5 Orientación a Objetos y Diseño Orientado a Objetos
Wirfs-Brock, Rebecca, Brian Wilkerson, and Lauren Wiener. Designing
Object-Oriented Software. NJ: Prentice Hall, 1990. ISBN 0-13-629825-7.
Coad, Peter. Object Models: Strategies, Patterns And Applications, 2nd
Edition. Prentice Hall PTR, 1996. ISBN 0-13-840117-9.
Entsminger, Gary. The Tao Of Objects. M & T Books, 1990. ISBN 1-55851-
155-5.
Goldberg, Adele and Kenneth S, Rubin. Succeeding With Objects. Addison-
Wesley, 1995. ISBN 0-201-62878-3.
Graham, Ian, Migrating To Object Technology. Addison-Wesley, 1995. ISBN
0-201-59389-0.
Jacobson, Ivar, Maria Ericsson, and Agneta Jacobson. The Object Advantage.
Addison-Wesley, 1995. ISBN 0-201-42289-1.
Taylor, David. Business Engineering With Object Technology. New York:
John Wiley, 1995. ISBN 0-471-04521-7
Taylor, David. Object Oriented Technology: A Manager’s Guide. Reading,
MA: Addison-Wesley, 1990. ISBN 0-201-56358-4

5.4.6 Arquitectura orientada a servicios (SOA)

Barry, Douglas K. Web Services and Service-Oriented Architectures: The
Savvy Manager’s Guide. Morgan Kaufmann, 2003. ISBN 1-55860-906-7.
Erl, Thomas. Service-Oriented Architecture: A Field Guide to Integrating
XML and Web Services. Prentice Hall, 2004. ISBN 0-131-42898-5.
Erl, Thomas. Service-Oriented Architecture: Concepts, Technology and
Design. Prentice Hall, 2004. ISBN 0-131-85858-0.

5.4.7 SQL
Celko, Joe. Joe Celko’s SQL for Smarties: Advanced SQL Programming,
3  Edition. ISBN 10: 0123693799. 840 paginas.
rd

Celko, Joe. Joe Celko’s Trees and Hierarchies in SQL for Smarties. Morgan
Kaufmann, 2004. ISBN 1-558-60920-2.
Date, C. J., with Hugh Darwen. A Guide to the SQL Standard, 4  Edition.
th

Addison-Wesley, 1997. ISBN 0-201-96426-0.

Kline, Kevin, with Daniel Kline. SQL in a Nutshell. O’Reilly, 2001. ISBN 0-
471-16518-2.
Van der Lans, Rick F. Introduction to SQL: Mastering the Relational Database
Language, 4  Edition. Addison-Wesley, 2006. ISBN 0-321-30596-5.
th

5.4.8 Mejora de procesos de Software

Humphrey, Watts S. Managing The Software Process. Addison Wesley, 1989.
ISBN 0-201-18095-2.

5.4.9 XML
Aiken, Peter and M. David Allen. XML in Data Management: Understanding
and Applying Them Together. Morgan Kaufmann, 2004. ISBN 0-12-45599-4.
Bean, James. XML for Data Architects: Designing for Reuse and Integration.
Morgan Kaufmann, 2003. ISBN 1-558-60907-5.
Finkelstein, Clive and Peter Aiken. Building Corporate Portals with XML.
McGraw-Hill, 1999. ISBN 10: 0079137059. 512 Paginas.
Melton, Jim and Stephen Buxton. Querying XML: XQuery, XPath and
SQL/XML in Context. Morgan Kaufmann, 2006. ISBN 1-558-60711-0.