Introducción

Si puede ver más del todo, se está acercando a

la verdad.

¿Por qué hay necesidad de este libro?

En muchos trabajos de consultoría de modelado de datos, los clientes se han hecho la misma pregunta: "¿Dónde
podemos encontrar un libro que muestre una forma estándar de modelar esta estructura? Seguramente, no somos la
primera compañía en modelar la compañía y abordar la información".

Muchas organizaciones desarrollan sus modelos de datos o diseños de depósito de datos con muy pocos
materiales de referencia externos. Un gran costo está asociado con la contratación de consultores experimentados o
con el uso de personal interno para desarrollar este componente crítico del diseño del sistema. A menudo no hay
material de referencia objetivo que la empresa pueda usar para validar sus modelos de datos o diseños de depósito de
datos o para buscar opciones alternativas para estructuras de bases de datos.

Basado en numerosas experiencias de usar plantillas o "modelos de datos universales" y

personalizarlos para varias empresas, hemos concluido que usualmente más del 50 por ciento del modelo
de datos (corporativo o lógico) consiste en construcciones comunes que son aplicables a la mayoría de las
organizaciones, otro El 25 por ciento del modelo es específico de la industria (estos modelos están
cubiertos en Los datos
Capítulo 1 **

Libro de recursos modelo, volumen 2), y, en promedio, alrededor del 25 por ciento del modelo de datos de la empresa
es específico de esa organización. Esto significa que la mayoría de los esfuerzos de modelado de datos están
recreando construcciones de modelado de datos que ya se han creado muchas veces antes en otras organizaciones.

Teniendo esto en cuenta, ¿no tiene sentido tener una fuente que utilizar para avanzar en su modelo
de datos para que no "reinvente la rueda" cada vez que una empresa desarrolla un nuevo sistema? Las
organizaciones pueden ahorrar tiempo y dinero al aprovechar el uso de estructuras de bases de datos
comunes o universales. Incluso si una empresa tiene modelos de datos de sus esfuerzos de desarrollo de
sistemas anteriores, es muy útil poder comparar los diseños con una fuente imparcial para evaluar
opciones alternativas.

Aunque una gran cantidad de publicaciones describen cómo modelar datos, existen muy pocas compilaciones
de ejemplos de modelos de datos en forma publicada. Este libro proporciona un punto de partida y una fuente para
validar modelos de datos. Puede ayudar a los modeladores de datos a minimizar los costos de diseño y desarrollar
diseños de bases de datos más eficaces e integrados.

¿Quién puede beneficiarse de leer este libro?

Este libro puede ayudar a muchos profesionales de desarrollo de sistemas diferentes: administradores de datos,
modeladores de datos, analistas de datos, diseñadores de bases de datos, administradores de depósitos de datos,
diseñadores de depósitos de datos, administradores de datos, integradores de datos corporativos o cualquier persona
que necesite analizar o integrar estructuras de datos. Los profesionales de sistemas pueden usar las construcciones de
bases de datos contenidas en este libro para aumentar su productividad y proporcionar un punto de control para diseños
de calidad.

La necesidad de modelos de datos universales

El modelado de datos ganó reconocimiento en el artículo de 1976 del Dr. Peter Chen, "EntityRelationship
Modeling", que ilustra su nuevo enfoque. Desde entonces, el modelado de datos se ha convertido en el enfoque
estándar utilizado para diseñar bases de datos. Al modelar adecuadamente los datos de una organización, el
diseñador de la base de datos puede eliminar las redundancias de datos, que son una fuente clave de información
inexacta y sistemas ineficaces.

Actualmente, el modelado de datos es un método conocido y aceptado para diseñar bases de datos efectivas.
Por lo tanto, existe una gran necesidad de proporcionar plantillas estándar a las empresas (el término "empresa"
se utiliza para describir las organizaciones para las que se están desarrollando los modelos y sistemas) para que
puedan refinar y personalizar sus modelos de datos en lugar de comenzar desde cero . Aunque existen muchos
estándares para el modelado de datos, existe una gran necesidad de llevar el modelado de datos al siguiente
paso: proporcionar accesibilidad a las bibliotecas de computadoras
 Introducción

Ejemplos de modelos de datos mon en un formato conveniente. Muchas organizaciones e industrias diferentes
deberían poder utilizar estas bibliotecas de modelos de datos. Tal modelos de datos universales puede ayudar a
ahorrar enormes cantidades de tiempo y dinero gastado en el proceso de desarrollo de sistemas.

Un enfoque holístico para el desarrollo de

sistemas

Uno de los mayores desafíos para construir sistemas efectivos es la integración. Los sistemas a menudo se construyen por
separado para satisfacer necesidades particulares en diferentes momentos dentro de cada empresa. Las empresas
necesitan construir muchos sistemas: sistemas de gestión de contactos, sistemas de pedidos de ventas, sistemas de
gestión de proyectos, sistemas de contabilidad, sistemas de presupuestos, sistemas de órdenes de compra y sistemas de
recursos humanos, por nombrar algunos.

Cuando los sistemas se crean por separado, se crean grupos de información separados para cada
sistema. Muchos de estos sistemas utilizarán información común sobre organizaciones, personas,
ubicaciones geográficas o productos. Esto significa que cada sistema separado construirá y usará su
propia fuente de información. Un gran problema con este enfoque es que es casi imposible mantener
información precisa y actualizada porque el mismo tipo de información se almacena de forma
redundante en muchos sistemas. En organizaciones grandes, no es raro ver información sobre
clientes, empleados, organizaciones, productos y ubicaciones almacenadas en docenas de sistemas
separados. ¿Cómo es posible saber qué fuente de información es la más actual o la más precisa?

Otra desventaja de construir sistemas separados con estructuras de datos no integradas es que la
empresa (la organización para la cual se están diseñando los modelos y sistemas) no tiene el
beneficio de ver información integrada. Poder ver un perfil completo de una persona, organización,
producto o artículo de inventario es un beneficio enorme. Imagine sistemas construidos para que
cada parte de una organización sepa lo que está haciendo la otra parte, donde los departamentos de
servicio al cliente, ventas, compras y contabilidad de una organización han integrado información
sobre las personas, organizaciones y productos de la empresa. Esta integración puede hacer una
gran diferencia en el servicio, las ventas y el rendimiento de una empresa.

Otra forma de abordar el desarrollo de sistemas es desde la perspectiva de que los sistemas de una
empresa están conectados y, de hecho, pueden verse como un sistema interconectado. Desde esta
perspectiva, la creación de un marco para toda la empresa ofrece enormes beneficios para que los sistemas
puedan trabajar juntos de manera más eficaz. Parte de este marco debe incluir un modelo de datos
corporativos (es decir, un modelo de datos empresariales) que pueda ayudar a la empresa a mantener uno
de sus activos más valiosos: la información. Porque cada sistema o aplicación puede usar
Capítulo 1

información similar sobre personas, organizaciones, productos y ubicaciones geográficas, una arquitectura de
información compartida puede ser invaluable. La industria IS (sistemas de información) ha reconocido la
necesidad de diseños integrados, lo que ha llevado a muchos esfuerzos de modelado de datos corporativos y
almacenamiento de datos corporativos. Desafortunadamente, el historial de IS para construir e implementar
modelos de datos corporativos ha sido muy pobre. Las empresas se han dado cuenta de que se necesita una
enorme cantidad de tiempo y recursos para construir estos modelos.

Ingrese las herramientas CASE (Ingeniería de sistemas asistida por computadora). Estas herramientas demandaron
una tremenda productividad y ahorro de tiempo cuando se usaron para los esfuerzos de modelado de toda la empresa.
Si bien estas herramientas ayudan a documentar los modelos, desafortunadamente no reducen el tiempo necesario para
desarrollar buenos modelos corporativos.
Muchas empresas han dejado de construir modelos de datos corporativos debido a sus limitaciones de
tiempo. Están analizando el historial del modelado de datos corporativos y los esfuerzos de CASE y
eligiendo otras alternativas.
Entrar almacenamiento de datos. Finalmente, aquí hay un enfoque para proporcionar a los ejecutivos la
información de gestión que necesitan, sin todo el tiempo y el gasto del modelado de datos corporativos. Las
empresas ahora están extrayendo las diversas piezas de información que necesitan directamente de sus
sistemas operativos para construir sistemas de soporte de decisiones.

El único problema con este enfoque es que ¡El mismo problema existe! En primer lugar, la
información en el almacén de datos se puede extraer de varias fuentes diferentes e
inconsistentes. Si hay varios lugares donde se mantiene la información del cliente, ¿qué sistema
representa la fuente de información más precisa?

De acuerdo con los principios de almacenamiento de datos, las rutinas de transformación son
responsables de consolidar y limpieza los datos. Si diferentes departamentos tienen diferentes necesidades
de varios datos, entonces cada departamento puede construir sus propios extractos de los sistemas
operativos. Un departamento puede transformar la información usando un algoritmo; un departamento
diferente puede usar otro algoritmo. Por ejemplo, si dos departamentos extraen información de análisis de
ventas, un departamento puede usar el sistema de ingreso de pedidos como su fuente y otro departamento
puede usar el sistema de facturación como su fuente. Un gerente de alto nivel puede ver información de
ambos almacenes de datos y ver resultados inconsistentes, cuestionando así la credibilidad de todas la
información. Este tipo de escenario en realidad agrava el problema inicial de muchas fuentes de datos al
crear aún más rebanadas de datos.

Esto no quiere decir que el almacenamiento de datos sea el enfoque incorrecto. Es un enfoque ingenioso
que se puede utilizar de manera extremadamente eficaz no solo para crear sistemas de soporte de decisiones,
sino también para construir una ruta de migración a un entorno integrado. El proceso de transformación del
almacén de datos ayuda a identificar dónde hay inconsistencias de datos y redundancias de datos en el
entorno operativo. Sin embargo, es imprescindible utilizar esta información para migrar a estructuras de datos
más integradas.
 Introducción

La respuesta sigue siendo construir estructuras de datos integradas para proporcionar información buena y
precisa. La única forma efectiva de hacer esto es comprender cómo los datos dentro de una empresa y las
relaciones se unen y poder ver los datos de una manera integrada y holística. Es necesario comprender la
naturaleza de los datos para construir sistemas efectivos. En lugar de decir eso, modelado de datos
corporativos o CASE. es el enfoque equivocado porque lleva demasiado tiempo, la comunidad de IS necesita
encontrar una manera de hacer que funcione de manera efectiva. Al construir estructuras de datos comunes y
reutilizables, la comunidad IS puede producir resultados más rápidos y avanzar hacia estructuras integradas
tanto en el procesamiento de transacciones como en los entornos de almacenamiento de datos.

¿Cuál es la intención de este libro y estos modelos?

La mayoría de los libros de modelado de datos se centran en las técnicas y metodologías detrás
del modelado de datos. El enfoque detrás de este libro es dramáticamente diferente. Este libro
supone que el lector sabe cómo modelar datos. El modelado de datos ha existido el tiempo
suficiente para que la mayoría de los profesionales de sistemas de información estén
familiarizados con este concepto y puedan entender este libro. Por lo tanto, este libro no hace
esfuerzos para enseñar principios de modelado de datos, excepto por ejemplo. Los
modeladores de datos pueden usar este libro, y su experiencia previa, para construir y refinar
los ejemplos de modelos de datos contenidos en el libro para desarrollar modelos de datos más
personalizados. Esencialmente, le da al modelador herramientas fundamentales y bloques de
construcción que pueden reutilizarse. Por lo tanto,

Además, el lector también puede beneficiarse de los modelos de depósito de datos que son aplicables a los
entornos de soporte de decisiones. Este libro no solo presenta ejemplos de diseños de almacenes de datos, sino
que también explica en detalle cómo convertir los modelos de datos lógicos en un almacén de datos de toda la
empresa, y luego en mercados de datos departamentales. Los modelos de datos lógicos y los modelos de
depósito de datos presentados aquí son aplicables en una amplia variedad de empresas.

Estos modelos están destinados a ser un punto de partida para desarrollar modelos de datos lógicos y de
almacenamiento de datos para una empresa. Cada empresa tendrá sus propios requisitos detallados; los
modelos deberán modificarse y personalizarse para poder implementarse en una empresa específica. Debido a
que los modelos de datos del almacén de datos reflejan los diseños reales de la base de datos (a diferencia de
los modelos de datos lógicos), dependen aún más de las necesidades comerciales de la empresa específica
que desea utilizar estos modelos. Además, los modelos de este libro se pueden usar para validar los modelos
de datos existentes de una empresa.

Los modelos presentados en la primera parte de este libro (capítulos 2 a 9) son modelos de datos lógicos, no
diseños de bases de datos físicas. Por lo tanto, estos modelos son
Capítulo 1 _____

normalizado y puede requerir cierta desnormalización al diseñar la base de datos física. De acuerdo
con este punto, los modelos de datos lógicos no incluyen ningún atributo derivado porque los atributos
derivados no agregan nada a los requisitos de información de una empresa. Simplemente sirven para
mejorar el rendimiento de la base de datos física.

Estos modelos de datos lógicos representan posibles requisitos de datos para las empresas. No incluyen muchas
de las reglas de procesamiento de negocios que pueden acompañar a los modelos de datos. Los modelos de datos
generalmente proporcionan toda la información necesaria para hacer cumplir las reglas comerciales; sin embargo, se
aconseja al lector en muchos casos que es posible que se deban desarrollar reglas comerciales adicionales para
complementar los modelos de datos. En este libro se proporcionan ejemplos de la necesidad de reglas comerciales.

Estos modelos de datos fueron diseñados para beneficiar a muchas industrias y empresas diferentes. Se
seleccionaron específicamente porque representan construcciones de datos muy comunes que aparecen en
la mayoría de las organizaciones. Dentro de estos modelos, siempre que hubo una decisión de modelado de
datos que pudo haber dependido de una empresa específica, se eligió la opción de modelado de datos más
flexible para acomodar muchas empresas diferentes.

Además, el capítulo sobre Implementación de modelos de datos universales proporciona una explicación sobre
cómo usar los modelos de datos para construir un modelo de datos empresariales, modelos de datos lógicos y
diseños de bases de datos físicas. Se proporcionan ejemplos detallados sobre cómo transformar los modelos de
datos en un diseño de base de datos física que se puede implementar para un sistema de gestión de bases de datos.

¿Qué hay de nuevo en la segunda edición de la

Libro de recursos del modelo de datos?

La segunda edición de la Libro de recursos del modelo de datos proporciona muchas mejoras y modelos
adicionales. Hay una gran cantidad de actualizaciones y adiciones; Los siguientes puntos los describen
a un alto nivel. Una gran mayoría de los modelos de datos en el original Libro de recursos del modelo de
datos se han mejorado significativamente con entidades, atributos y relaciones adicionales.

Muchos de los modelos de datos tienen estructuras de datos ligeramente diferentes y más mejoradas.
Basado en numerosos usos e implementaciones de estos modelos, los modelos se han actualizado para
reflejar estructuras de datos aún más efectivas. Se han agregado varios capítulos nuevos a la segunda edición.
El Capítulo 14 proporciona esquemas en estrella adicionales que pueden usarse como plantillas para
soluciones de análisis de datos. El Capítulo 15 proporciona una explicación de cómo usar los modelos de datos
universales para crear un modelo de datos empresariales, un modelo de datos lógico,
 Introducción

y un diseño de base de datos física. Este capítulo proporciona ejemplos de personalización de modelos de
datos empresariales y lógicos y varios ejemplos de diseño de bases de datos físicas para implementar uno de
los modelos de datos universales. Se ha agregado una gran cantidad de nuevos modelos de datos
universales a la biblioteca integral ya existente desde la primera edición. La Tabla 1.1 proporciona una lista de
los nuevos modelos.

Tabla 1.1 Modelos de datos agregados en la segunda edición

CAPÍTULO NUEVOS MODELOS DE DATOS QUE SE HAN AGREGADO DE LA

PRIMERA EDICIÓN A LA SEGUNDA EDICIÓN

2 fiestas 2b Persona: modelo alternativo

2.4 Roles de partido
2.5 Relaciones de partido específicas
2.6 Relaciones comunes del partido
2.11 Instalación versus mecanismo de contacto
2.12 Evento de comunicación del partido
2.13 Evento de comunicación evento de seguimiento

3 productos 3.4 Característica del producto

3.10a Productos y partes

3.10b Productos y piezas: modelo alternativo

4 pedidos 4.3 Partes de pedidos de venta y mecanismos de contacto

4.4 Partes de orden de compra y mecanismos de contacto
4.6 Ajustes de pedido
4.12 Roles de acuerdo

5 envíos 5.4 Recibo de envío para envíos entrantes

5.5 Emisiones de artículos para envíos salientes
5.6 Documentos de envío
5.7 Segmentos de ruta de envío

6 esfuerzos de trabajo 6.1 Requisito de trabajo

6.2 Roles de requisitos de trabajo
6.12 Resultados del esfuerzo laboral

7 facturas 7.8a Pagos de facturas

7.8b Modelo de pago alternativo de facturas
7.9 Cuentas financieras, retiros y depósitos

8 contabilidad 8.2 Transacciones comerciales versus transacciones contables

8.4 Asociaciones de cuentas de contabilidad general y cuentas de contabilidad subsidiarias

8.7 Revisión del presupuesto

8.8 Revisión de revisión del presupuesto

8.9 Escenario presupuestario

Continúa
8 Capítulo 1

Tabla 1.1 Modelos de datos agregados en la segunda edición ( Continuado)

CAPÍTULO NUEVOS MODELOS DE DATOS QUE SE HAN AGREGADO DE LA

PRIMERA EDICIÓN A LA SEGUNDA EDICIÓN

9 Recursos humanos 9.8 Seguimiento de beneficios

9.10 Solicitud de empleado

9.11 Habilidades y calificaciones de los empleados
9.12 Desempeño de los empleados
9.13 Despido de empleados

12 diseños de esquema de estrella para 12.2 Datos de ventas orientados a transacciones mercado

análisis de ventas diseños de esquema de

estrella

14 diseños de esquemas de 14.1 Esquema en estrella de gestión de inventario

estrellas adicionales 14.2 Esquema de estrella de orden de compra

14.3 Esquema de estrella de envío

14.4 Esquema de estrella del esfuerzo de trabajo

14.5 Esquema estrella de análisis financiero

15 Implementación de modelos de datos 15.2 Mecanismo personalizado de contacto con la parte (usando
universales diferentes términos)

15.3 Adiciones al modelo de mecanismo de contacto con la parte

15.4 Modelo detallado para la fuerza de ventas (que muestra una versión personalizada para
una aplicación en particular)

15.6 Opción de diseño físico de roles y relaciones de partido 1

15.7 Roles de partido y relaciones diseño físico opción 2
15.8 Roles de partido y relaciones opción de diseño físico 3

Convenciones y estándares utilizados en este

libro

La siguiente sección describe los estándares de nomenclatura y las convenciones de diagramación

utilizadas para presentar los modelos en este libro. Se proporcionan detalles para entidades, subtipos,
atributos, relaciones, claves foráneas, modelos físicos y tablas de ilustración.

Entidades

Un entidad es algo significativo sobre el cual la empresa desea almacenar información. Cuando se
hace referencia a entidades en todo el libro, se muestran en mayúsculas. Por ejemplo, ORDER
representa una entidad que almacena información sobre un compromiso entre las partes para
comprar productos. Cuando el nombre de una entidad se usa en una oración para ilustrar conceptos
y negocios.
 Introducción

Figura 1.1 Una entidad.

En cuanto a las reglas, se puede mostrar en texto normal, por ejemplo, "Muchas empresas tienen mecanismos como
un formulario de pedido de ventas para registrar la información del pedido de ventas". Las convenciones de
nomenclatura para una entidad incluyen el uso de un sustantivo singular que sea lo más significativo posible para
reflejar la información que mantiene. Además, el sufijo TYPE se agrega al nombre de la entidad si la entidad
representa una clasificación de información como un TIPO DE PEDIDO (es decir, orden de venta versus pedido de
compra) en lugar de una instancia específica de una cosa real como un PEDIDO ("orden

#2
#3987 ").
Los modelos de datos en este libro incluyen entidades TYPE en los diagramas, a pesar de que
generalmente solo tienen una identificación y una descripción. Estas entidades se incluyen para completar y
mostrar dónde se almacenan los valores permitidos o las búsquedas.

Las entidades se incluyen en el modelo de datos si es un requisito de la empresa mantener la

información incluida en la entidad. Por ejemplo, si a una empresa realmente no le importa rastrear
las tareas asociadas con un envío, aunque esta información exista en el mundo real, el modelo de
datos no debe incorporar esta información porque puede no ser información lo suficientemente
importante para la empresa mantener.

Las entidades están representadas por cuadros redondeados. La figura 1.1 muestra un ejemplo de la entidad
ORDEN.

Subtipos y Supertipos
UNA subtipo a veces referido como subentidad, es una clasificación de una entidad que tiene
características tales como atributos o relaciones en común con la entidad más general.
ORGANIZACIÓN LEGAL y ORGANIZACIÓN INFORMAL son, por ejemplo, subtipos de
ORGANIZACIÓN.
Los subtipos se representan en los diagramas de modelado de datos por entidades dentro de otras
entidades. Los atributos comunes y las relaciones entre subtipos se muestran en la entidad externa,
que se conoce como supertipo Por lo tanto, los atributos y las relaciones del supertipo son heredados
por el subtipo. La Figura 1.2 muestra la ORGANIZACIÓN de supertipo y sus subtipos ORGANIZACIÓN
LEGAL y ORGANIZACIÓN INFORMAL. Tenga en cuenta que el nombre se aplica a
10 Capítulo 1

Figura 1.2 Subtipos y supertipos.

supertipo ORGANIZACIÓN y el ID de impuestos federales se aplica solo al subtipo ORGANIZACIÓN

LEGAL. Por lo tanto, se muestra en el nivel de subtipo de ORGANIZACIÓN LEGAL porque se aplica
solo a ese subtipo. Tanto la ORGANIZACIÓN LEGAL como la ORGANIZACIÓN INFORMAL tendrían
un nombre porque heredarán los valores del supertipo.

Los supertipos pueden tener muchos niveles. La Figura 1.2 muestra que una AGENCIA CORPORATIVA y
GUBERNAMENTAL son subtipos de ORGANIZACIÓN LEGAL, que también es un subtipo de ORGANIZACIÓN.
Por lo tanto, los cuadros pueden estar en cuadros inferiores a cualquier nivel para ilustrar qué subtipos heredan los
atributos y las relaciones del supertipo principal (su cuadro externo).

Los subtipos dentro de una entidad deben representar un conjunto completo de clasificaciones (lo que
significa que la suma de los subtipos cubre el supertipo en su totalidad) y al mismo tiempo ser mutuamente
excluyentes entre sí (una excepción de manejar conjuntos separados de elementos no mutuamente
excluyentes). los subtipos se tratarán en la siguiente sección). Muchas veces el modelo de datos incluye un
subtipo OTRO ... para proporcionar otras posibles clasificaciones de la entidad que la empresa puede
definir utilizando el modelo. Por ejemplo, cada ORGANIZACIÓN DE INFORMACIÓN puede ser un
EQUIPO, FAMILIA u OTRA ORGANIZACIÓN INFORMAL.

Si bien los subtipos representan un conjunto completo de clasificaciones posibles, puede haber subtipos más
detallados que no están incluidos en el modelo de datos; en su lugar, pueden incluirse en una entidad TYPE. En
este caso, los subtipos se muestran en dos lugares en un modelo: como un subtipo y en una entidad TYPE que
muestra el dominio de los tipos permitidos para la entidad.
 Introducción 11

Conjuntos de subtipos no mutuamente excluyentes

A veces, los subtipos no son mutuamente excluyentes; en otras palabras, los supertipos pueden subtiparse de
diferentes maneras y puede aplicarse más de un conjunto de subtipos al mismo supertipo.

Considere la Figura 1.3, que muestra que un REQUISITO puede ser subtipado de diferentes
maneras. Un REQUISITO puede ser de un cliente (REQUISITO DEL CLIENTE) o puede
representar un requisito interno de la empresa (REQUISITO INTERNO). Al mismo tiempo, el
REQUISITO puede ser un requisito que establece la necesidad de un producto específico
(REQUERIMIENTO DEL PRODUCTO) o un requisito que establece la necesidad de trabajar
(REQUISITO DE TRABAJO).

Por lo tanto, podría ocurrir más de un subtipo para un REQUISITO; por ejemplo, podría ser un
REQUISITO DEL CLIENTE y un REQUISITO DEL PRODUCTO. La Figura 1.3 ilustra una convención para
mostrar conjuntos de subtipos mutuamente excluyentes al tener un cuadro alrededor de cada conjunto de
subtipos posibles sin nombre para el cuadro. Los cuadros simplemente sirven para establecer cuándo hay
más de un conjunto de subtipos para un supertipo.

Atributos
Un atributo contiene una información particular sobre una entidad, como
fecha de orden en un pedido Los atributos se identifican en el texto del libro en negrita, letras minúsculas
como las anteriores fecha de orden ejemplo. Los atributos pueden ser parte del identificador único de una
entidad (también conocida como clave primaria), obligatoria u opcional. Los atributos clave principales
son identi

Figura 1.3 Subtipos y supertipos no mutuamente excluyentes.

12 Capítulo 1

Figura 1.4 Atributos

Fied por un signo "#" que precede al nombre del atributo en el diagrama. Los atributos obligatorios se
indican con un "*" antes del nombre del atributo. Los atributos opcionales tienen una "o" antes del atributo.
La Figura 1.4 muestra que la entidad ORDEN tiene
Solicitar ID como un atributo de clave principal, fecha de orden como un atributo obligatorio, y
fecha de entrada como un atributo opcional
Ciertas cadenas incluidas en el nombre de un atributo tienen significados basados ​en las convenciones que se
muestran en la Tabla 1.2.

Relaciones
Relaciones definir cómo se asocian dos entidades entre sí. Cuando se usan relaciones en el texto,
generalmente se muestran en minúsculas como parte normal del texto. En algunas situaciones,
donde se resaltan específicamente, se identifican con letras minúsculas en negrita. Por ejemplo, fabricado
por podría ser la forma en que puede aparecer una relación en el texto de este libro.

Opcionalidad de relación

Las relaciones pueden ser opcionales u obligatorias. Una línea de relación punteada junto a una
entidad significa que la relación de esa entidad es opcional, y una línea continua significa que la
relación es obligatoria (la relación debe existir para todas las ocurrencias de cada entidad). La
Figura 1.5 muestra una relación que "cada ENVÍO debe ser enviado desde una y solo una
DIRECCIÓN POSTAL ". Esto significa que la dirección postal de cada envío debe especificarse
para crear una instancia de envío. La misma relación tiene un aspecto opcional cuando se lee en la
otra dirección:" Cada DIRECCIÓN POSTAL tal vez la fuente de uno o más ENVÍOS ". Por lo tanto,
podría haber una dirección postal que aún no se haya utilizado para un envío.

Relación cardinalidad

Las relaciones pueden ser uno a uno, uno a muchos o muchos a muchos. Esto se conoce generalmente como
la cardinalidad de la relación. La presencia de un pata de Cuervo ( una línea de tres puntas que se parece a una
pata de gallo) define si una entidad apunta
 Introducción 13

Tabla 1.2 Convenciones utilizadas en la denominación de atributos

CADENA CON NOMBRE DE ATRIBUTO SENTIDO

CARNÉ DE IDENTIDAD Identificador numérico único secuencial generado por el sistema (es
decir, 1, 2, 3, 4, ...)

Seqid Secuencia generada por el sistema dentro de una ID principal (por ejemplo,

número de secuencia de línea de orden)

Código Neumónico único: se utiliza para identificar identificadores únicos definidos por el
usuario que pueden tener algún significado incrustado en la clave (es decir, un
ejemplo de un código geográfico para almacenar Colorado puede ser "CO")

Nombre Un pronombre apropiado como persona, área geográfica,

organización

Descripción El valor descriptivo de un código o identificador único

Indicador o Ind (indicador) Una opción binaria para valores (es decir, sí / no o **

Macho femenino)

partir de la fecha Atributo que especifica la fecha de inicio de un rango de

fechas e incluye la fecha especificada

hasta la fecha Atributo que especifica la fecha de finalización de un rango de fechas e

incluye la fecha especificada ( hasta la fecha no se usa porque hasta la
fecha representa más claramente un rango de final de fecha inclusivo)

a más de una ocurrencia de otra entidad. La Figura 1.6 muestra que "cada ORDEN debe ser compuesto
de uno o mas ARTÍCULOS DE PEDIDO "porque la pata de gallo está en el lado del ARTÍCULO DE
PEDIDO. El otro lado de la relación establece que" cada ARTÍCULO DE PEDIDO debe ser parte de uno
y solo uno ORDEN ". Una relación uno-a-uno no tiene patas de gallo en la relación, y una relación de
muchos a muchos tiene patas de gallo en ambos extremos de la relación. A veces, las relaciones de
uno a muchos se denominan padre-hijo relaciones. A veces, el término "a lo largo del tiempo" debe
agregarse a la oración de relación para verificar si la relación es de uno a muchos. Por ejemplo, un
ORDEN puede parecer que solo tiene un ESTADO DE PEDIDO; sin embargo, si se requiere un historial
de estado , cada ORDEN puede estar en el estado de uno o más ESTADOS DE PEDIDO, tiempo
extraordinario.

Los modelos de datos en el libro tienen muy pocas relaciones uno a uno porque la mayoría de las
veces las relaciones uno a uno se pueden agrupar en una sola entidad cuando se normaliza. Los
diagramas del modelo de datos no muestran relaciones de muchos a muchos porque las relaciones de
muchos a muchos casi siempre se dividen en intersección entidades.
14 Capítulo 1

Figura 1.5 Relaciones obligatorias versus opcionales.

Relaciones clave extranjeras

Una clave foránea se define como la presencia de la clave primaria de otra entidad (o tabla) en una entidad (o
tabla). Por ejemplo, en la Figura 1.6 el Solicitar ID de la entidad ORDEN es parte de la entidad ARTÍCULO DE
PEDIDO; por lo tanto, es una clave foránea. Cualquier relación de uno a muchos indica que la clave principal
de la entidad en el
uno lado de la relación se lleva a la entidad en el muchos lado de la relación. Algunos modeladores de datos
muestran esta clave externa como un atributo de la entidad (a veces esto se conoce como migración de
clave). Los modelos de datos en este libro no muestran las claves foráneas de las entidades como atributos
porque esto es redundante.

Figura 1.6 Relación uno a muchos.

 Introducción 15

En cambio, la relación misma identifica la clave foránea. En la figura 1.6, el Solicitar ID no se muestra
como un atributo en la entidad ELEMENTO DE PEDIDO porque la naturaleza única de la relación revela
que es una clave externa.

Herencia de clave extranjera

Una convención de diagramación en este libro es usar una línea de relación tilde ("~") para indicar que la
clave externa heredada es parte de la clave primaria de la entidad secundaria. La línea tilde ("~") a través
de la relación en la Figura 1.6 indica que el Solicitar ID forma parte de la clave primaria de la entidad
ORDEN ARTÍCULO. Esta convención permite una notación abreviada, proporcionando que la clave
primaria se identifique como una combinación de los atributos de la clave primaria (identificados con un
"#"), así como las claves primarias de la entidad a la que apunta la relación con una tilde.

Por lo tanto, la clave principal del PEDIDO es ID del artículo del pedido
más la clave principal de la orden, orden carné de identidad.
Esta convención permite una notación abreviada para documentar las claves primarias de cada entidad
sin ocupar mucho espacio mediante claves externas repetidas que forman parte de la clave primaria de
otra entidad. Esta notación también muestra la semántica de la clave primaria al especificar claramente las
relaciones que conforman la clave primaria, así como cualquier atributo con un símbolo "#" al lado de ellos.

Entidades de intersección o asociación para manejar

relaciones de muchos a muchos

Las entidades de intersección también se conocen como entidades asociativas o entidades de referencia
cruzada. Se utilizan para resolver relaciones de muchos a muchos haciendo referencia cruzada de una entidad a
otra. A menudo incluyen atributos adicionales que pueden delinear aún más la relación. La Figura 1.7 muestra
una relación de muchos a muchos entre una PARTE y un MECANISMO DE CONTACTO que se resuelve de
esta manera. El diagrama indica que se puede contactar a una PARTE a través de más de uno MECANISMO DE
CONTACTO, como una DIRECCIÓN POSTAL, NÚMERO DE TELECOMUNICACIONES o DIRECCIÓN
ELECTRÓNICA porque una parte puede tener muchas formas de ser contactada. Por el contrario, un
MECANISMO DE CONTACTO puede ser utilizado por más de uno FIESTA. Por ejemplo, muchas personas
pueden tener la misma dirección o número de teléfono del trabajo. Esta relación de muchos a muchos es
resuelta por la entidad de intersección MECANISMO DE CONTACTO DE LA PARTE. Cada entidad asociativa
hereda la clave de cada una de las entidades que intersecta. Por lo tanto, la tilde ("~") siempre se usa en las
relaciones de referencia de una entidad asociativa para mostrar que la entidad asociativa hereda la clave de
cada una de las entidades referenciadas (ver "herencia de clave externa" mencionada en la última sección). Por
ejemplo, la identificación de la parte y la identificación del mecanismo de contacto son partes de la clave
principal del MECANISMO DE CONTACTO DE LA PARTE, junto con la fecha de inicio.
dieciséis Capítulo 1

Figura 1.7 Relaciones de muchos a muchos.

Observe que en todos los ejemplos dados, cada relación tiene dos nombres de relación asociados
que describen la relación en ambas direcciones. Los nombres de las relaciones deben combinarse para
que se lean como una oración completa, como se muestra en el siguiente formato: "Cada ENTIDAD
{debe ser / puede ser} nombre de la relación {uno y solo uno / uno o más} ENTIDAD, con el tiempo"
donde se completan las opciones apropiadas.

En los modelos presentados, las patas de gallo en las relaciones generalmente apuntan hacia arriba y hacia la
izquierda para proporcionar un mecanismo consistente para leer los diagramas. Esto tiende a organizar los
modelos de datos en un formato más comprensible.

Arcos exclusivos

Los arcos exclusivos se usan para identificar relaciones donde una entidad está relacionada con otras dos o
más entidades, pero solo puede existir una relación para una ocurrencia de entidad específica. El arco
exclusivo está representado por una línea curva que atraviesa dos o más líneas de relación. La figura 1.8
muestra un ejemplo de un arco exclusivo. Las relaciones se leen como "Cada ARTÍCULO DE INVENTARIO
debe ser ya sea ubicado en una y solo FACILIDAD o debe ubicarse dentro de un solo CONTENEDOR,

pero no ambos." Esto comunica que los artículos de inventario se almacenan en uno de dos tipos de niveles:
se ubican en instalaciones como un almacén o se almacenan en contenedores como un contenedor ubicado
dentro de una instalación.
 Introducción 17

Figura 1.8 Arcos exclusivos.

Relaciones recursivas

Las relaciones recursivas son relaciones que muestran cómo se relaciona una entidad consigo misma. Por ejemplo, una
relación recursiva podría modelarse ya sea a través de una relación que apunta desde una entidad hacia sí misma o
mediante una relación de muchos a muchos. Esto depende de si es una recursión de muchos a muchos o una recursión
de uno a muchos. Es posible que una entidad tenga muchas relaciones recursivas. La Figura 1.9 muestra un ejemplo de
una recursión de uno a muchos alrededor de la entidad de ESFUERZO DE TRABAJO para mostrar que los esfuerzos
de trabajo pueden rehacerse. También muestra una recurrencia de muchos a muchos que es resuelta por la entidad de
intersección ASOCIACIÓN DE ESFUERZO DE TRABAJO para mostrar que los esfuerzos de trabajo pueden depender
de otros esfuerzos de trabajo (subtipo DEPENDENCIA DE ESFUERZO DE TRABAJO) o dividirse en varios esfuerzos
de trabajo de nivel inferior (ESFUERZO DE TRABAJO Desglose subtipo).

Modelos físicos
Los modelos y diagramas del almacén de datos (capítulos 10 a 14), así como algunos de los modelos del
Capítulo 15, representan diseños de bases de datos físicas. los
 Figura 1.9 Relaciones recursivas

Se pueden usar las mismas anotaciones como se indicó anteriormente, con la excepción de que debido a que estos
modelos representan diseños de bases de datos físicas, cada cuadro representa una tabla y los nombres de campo
son columnas.

Convenciones utilizadas para tablas de ilustración

Muchas partes de los modelos de datos se ilustran mediante tablas que contienen posibles valores para los
atributos. Cada tabla de ilustración se define normalmente para mostrar una entidad específica y la información
relevante de entidades relacionadas. Por ejemplo, puede haber una tabla que ilustra la entidad ARTÍCULO DE
PEDIDO, como se muestra en la Tabla 1.3. Para ilustrar los detalles de un ARTÍCULO DE PEDIDO, la Tabla 1.3
trae información de atributos de la entidad ORDEN. Siempre que los datos de cada ilustración

Tabla 1.3 Articulo ordenado

SOLICITAR ID FECHA DE ORDEN COMENTARIO

ID DE SECUENCIA DEL ARTÍCULO DE PEDIDO

12930 30 de abril de 1995 1 Necesita este artículo con urgencia

No hay presión de tiempo en absoluto en este artículo

 Introducción 19

La tabla de tración está referenciada en el texto de este libro, está rodeada de comillas dobles. Por ejemplo, el texto
puede referirse al pedido específico "12930", el ítem de pedido seq id "1", que tiene un comentario de "Necesita este
ítem con urgencia".

Convenciones utilizadas para las figuras de referencia

Porque hay dos volúmenes para el Libro de recursos del modelo de datos, Las cifras están referenciadas por la
siguiente notación:

Vx: Figura xx

Donde Vx significa una referencia al Volumen 1 o al Volumen 2

y La figura xx hace referencia a una figura específica en ese volumen.

Por ejemplo, Vl: 2.1 hace referencia a la Figura 2.1 en el Volumen 1, el modelo de datos de la
Organización. V2: 2.2 referencias Figura 2.2 (Partes y productos) en el segundo volumen. Si no hay Vx
delante de la referencia, entonces el lector puede suponer que la cifra está en el volumen actual.

El CD-ROM complementario

Este libro y sus apéndices proporcionan descripciones muy detalladas de los modelos
discutidos. Los diagramas presentan todas las relaciones, los atributos obligatorios y las
columnas, las claves principales, e incluso incluyen algunos atributos opcionales. Los
apéndices incluyen los detalles físicos de los atributos y las columnas, como el tipo de
datos y el tamaño. Con esta información, un modelador de datos o diseñador de bases de
datos podría recrear estos modelos en la herramienta que elija o escribir el código SQL
para construirlos en una base de datos. Sin embargo, esto llevaría una cantidad
considerable de tiempo y abre la posibilidad de errores de entrada de datos. Para ayudar a
aquellos interesados ​en implementar rápidamente los modelos descritos en estas páginas,
los modelos se proporcionan en forma electrónica en el CD-ROM complementario (que
debe desbloquearse y / o comprarse por separado). (Ver "
20 capitulo l

El uso de los scripts en el CD-ROM permitirá a una empresa implementar más rápidamente los modelos
presentados en este libro. Además del ahorro de tiempo, obviamente también hay un ahorro de costos (nadie tiene que
escribir todas las definiciones o escribir scripts SQL). Una vez que se han ejecutado las secuencias de comandos, los
modelos se pueden realizar ingeniería inversa en la herramienta CASE favorita de la empresa (las herramientas CASE
más populares proporcionan una función de ingeniería inversa). Una vez que los modelos se han llevado a un
repositorio, son fácilmente accesibles y pueden personalizarse para las necesidades específicas de una empresa.
Además, se pueden usar para impulsar el desarrollo de modelos de datos corporativos, nuevas aplicaciones, diseños
de almacenamiento de datos o sistemas de soporte de decisiones.

El CD-ROM también contiene los diagramas del modelo de datos en formatos electrónicos y una serie de
informes que enumeran y hacen referencias cruzadas a las áreas de datos, entidades, atributos, tablas y columnas
de los modelos de datos.
El resto de este libro proporcionará muchos ejemplos de modelos de datos universales y diseños de
depósito de datos que pueden ayudar a aumentar la productividad de los esfuerzos de desarrollo del
sistema. Se proporcionarán ejemplos detallados de cómo implementar estos modelos en el capítulo 15,
"Implementación de modelos de datos universales".