hogar / Problemas/ El modelo de datos empresariales incluye elementos. Modelo de datos relacionales

El modelo de datos empresariales incluye elementos. Modelo de datos relacionales

Este artículo se centrará en la arquitectura del almacén de datos. Qué debe guiarse al construirlo, qué enfoques funcionan y por qué.

"El cuento es una mentira, pero hay una pista en él ..."

Abuelo plantó ... almacenamiento. Y el almacén ha crecido, genial, genial. Realmente no sabía cómo funcionaba. Y el abuelo comenzó una revisión. El abuelo llamó a la abuela, nieta, gato y ratón al consejo familiar. Y dice lo siguiente: “Nuestro almacenamiento ha crecido. Los datos de todos los sistemas fluyen hacia abajo, las tablas son visibles e invisibles. Los usuarios elaboran sus informes. Todo parece ir bien: vivir y vivir. Sí, solo una tristeza: nadie sabe cómo funciona. Requiere discos aparentemente invisibles, ¡no puedes guardar lo suficiente! Y luego los usuarios se acostumbraron a acudir a mí con diferentes quejas: o el informe se congela o los datos están desactualizados. Y luego es todo un desastre: venimos con informes para el padre zar, pero los números no coinciden entre sí. La hora no es par - el rey está enojado - entonces no le quites la cabeza - ni por mí, ni por ti. Así que decidí reunirlos y consultarlos: ¿qué vamos a hacer? "

Lanzó su mirada sobre la reunión y pregunta:
- Tú, abuela, ¿sabes cómo está organizado nuestro almacenamiento?
- No, abuelo, no lo sé. ¿Y cómo lo sabría? ¡Ahí, qué valientes lo custodian! ¡Algunos! No te acercarás. Fui a verlos de alguna manera, pasteles horneados. Y se comieron las empanadas, se limpiaron el bigote y dijeron: “¿Por qué viniste abuela? ¿Qué tipo de almacenamiento eres? Dígame qué tipo de informe necesita, ¡lo haremos por usted! ¡Deberías traer las tartas con más frecuencia! Dolorosamente, son deliciosos ".
- Y tú, querida nieta, ¿sabes cómo está organizado nuestro almacenamiento?
- No, abuelo, no lo sé. Me dieron acceso a él de alguna manera. Conecté, miro - y hay mesas - aparentemente invisible. Y se ocultan diferentes esquemas. Los ojos se mueven hacia arriba…. Al principio estaba confundido. Y luego miré de cerca: algunos de ellos están vacíos, otros están llenos, pero solo la mitad. Y los datos parecen repetirse. ¡No es de extrañar que no haya suficientes discos, con tanta redundancia!
- Bueno, tú, gato, ¿qué dices de nuestra instalación de almacenamiento? ¿Tiene algo de bueno?
- Sí, como no decirlo, abuelo - Lo haré. A pedido de mi nieta, traté de hacer un piloto en un circuito separado: una pequeña exhibición. Para comprender qué tipo de comercio es rentable para nuestro estado, qué productos son buenos para los comerciantes, pagan tributo, reponen el tesoro. Y cuáles son muy malos. Y comencé a seleccionar datos para mí de este repositorio. Hechos recopilados. Y comenzó a intentar compararlos con productos. Y qué, abuelo, vi, los productos parecen ser los mismos, pero miras los platos, ¡son diferentes! Entonces comencé a peinarlos con el peine de mi nieta. Chesal-rayado - y dio lugar a una cierta uniformidad, acariciando los ojos. Pero al principio me regocijé, al día siguiente lancé mis scripts para actualizar los maravillosos datos en la ventana, ¡y todo desapareció para mí! "¿Cómo es eso?" - Creo - la nieta estará disgustada - hoy sería necesario mostrarle nuestro piloto al ministro. ¿Cómo vamos con esos datos?
- Sí, cuentos tristes, gato, lo dices. Bueno, tú, ratoncito, ¿de verdad no trataste de averiguar sobre el almacenamiento? ¡Eres una chica vivaz, ágil y sociable con nosotros! ¿Qué nos dirás?
- Sí, cómo, abuelo, no lo intentes - claro, soy un ratón tranquilo, sí ágil. Una vez, la nieta del gato me pidió que obtuviera el modelo de datos de nuestro almacenamiento estatal. Y el gato, por supuesto, vino a mí, para ti, dice, el ratón, ¡toda esperanza! Bueno, ¿qué es una buena acción que las buenas personas (y los gatos) no deben hacer? Fui al castillo, donde el jefe del almacén esconde el modelo de datos en la caja fuerte. Y ella se escondió. Esperé a que sacara ese modelo de la caja fuerte. Tan pronto como salió a tomar un café, salté a la mesa. Miro el modelo, ¡no entiendo nada! ¿Cómo es eso? ¡No reconozco nuestro almacenamiento! Tenemos innumerables miles de tablas, ¡los flujos de datos son incontenibles! Y aquí, todo es armonioso y hermoso ... Miró este mismo modelo y lo volvió a guardar en la caja fuerte.
- Sí, cosas muy raras, nos dijiste, ratón.
El abuelo pensó mucho.
- ¿Qué vamos a hacer, amigos míos? Después de todo, con tal o cual repositorio no vivirás mucho ... Los usuarios pronto perderán la paciencia.

Independientemente de lo que nuestro abuelo haya decidido de un cuento de hadas, construir una nueva instalación de almacenamiento o intentar reanimar una existente, es necesario sacar conclusiones antes de "arremangarnos" nuevamente.
Dejemos a un lado los aspectos organizativos, como el peligro de concentración de conocimientos especializados en un grupo cerrado y estrecho, la ausencia de procesos de control y garantizar la transparencia de la arquitectura de los sistemas utilizados en la empresa, etc.
Hoy me gustaría centrarme en construir la arquitectura de un sistema específico (o grupo de sistemas): almacenes de datos. Lo que debe mantenerse enfocado en primer lugar, cuando una organización comienza a construir un sistema tan complejo y costoso como el almacenamiento.

Interrogación

Ninguno de nosotros, trabajando en la creación y desarrollo de ningún sistema, no quiere que esto sea una "casa temporal", o una solución que "desaparecerá" en uno o dos años, porque no podrá cumplir con los requisitos y expectativas de los Clientes y la Empresa. No importa cuán fuerte se observe hoy el sesgo hacia las "metodologías flexibles", es mucho más agradable para una persona sentirse como un "maestro" que hace violines que un artesano que cepilla palos para tambores desechables.
Nuestra intención suena natural: hacer sistemas que sean sólidos y de alta calidad, que no requieran que tengamos "vigilias nocturnas con archivo" regulares, por lo que no nos avergonzaremos frente a los usuarios finales y que no se verán como una "caja negra" para todos los seguidores "no iniciados".

Para empezar, incluyamos una lista de problemas típicos que encontramos regularmente cuando trabajamos con repositorios. Escribamos lo que tenemos, hasta ahora sin intentar simplificarlo y formalizarlo.

En principio, tenemos un buen almacenamiento: si lo dejas solo, entonces todo funciona. Es cierto que tan pronto como se requiere un cambio, comienzan los “colapsos locales”.
Los datos se cargan diariamente, de acuerdo con las regulaciones, dentro de un gran proceso, dentro de las 8 horas. Y nos conviene. Pero si de repente ocurre una falla, es necesaria una intervención manual. Y luego todo puede funcionar de manera impredecible durante mucho tiempo, tk. requerirá la participación humana en el proceso.
Han enrollado el lanzamiento, espere problemas.
Alguna fuente no pudo enviar datos a tiempo; todos los procesos están esperando.
La integridad de los datos está controlada por la base de datos, por lo que nuestros procesos se bloquean cuando se rompen.
Tenemos un almacenamiento muy grande: 2000 tablas en un esquema común. Y 3000 más en muchos otros esquemas. Ya tenemos poca idea de cómo están organizados y por qué aparecieron. Por tanto, puede resultarnos difícil reutilizar algo. Y muchas tareas deben resolverse de nuevo. Porque esto es más fácil y rápido (que entender "el código de otra persona"). Como resultado, tenemos discrepancias y funcionalidad duplicada.
Esperamos que la fuente proporcione datos de buena calidad. Pero resulta que este no es el caso. Como resultado, dedicamos mucho tiempo a conciliar nuestros informes finales. Y tuvieron mucho éxito en esto. Incluso tenemos un proceso simplificado. Es cierto que lleva tiempo. Pero los usuarios están acostumbrados a ...
El usuario no siempre confía en nuestros informes y requiere una justificación de una cifra u otra. En algunos casos tiene razón y en otros no. Pero es muy difícil para nosotros justificarlos, ya que no tenemos ningún medio de "análisis de un extremo a otro" (o linaje de datos).
Podríamos traer desarrolladores adicionales. Pero tenemos un problema: ¿cómo los incluimos en el trabajo? ¿Cuál es la forma más eficiente de paralelizar trabajos?
¿Cómo desarrollar el sistema gradualmente, sin entrar en el desarrollo del "núcleo del sistema" durante todo un año?
El data warehouse está asociado al modelo corporativo. Pero sabemos con certeza (lo vimos en el banco XYZ) que construir un modelo puede ser infinitamente largo (fuimos al banco XYZ durante seis meses y discutimos las entidades comerciales, sin ningún movimiento). ¿Por qué está ella en absoluto? ¿O tal vez es mejor sin ella, si hay tantos problemas con ella? ¿Quizás podamos generarlo de alguna manera?
Decidimos conducir el modelo. Pero, ¿cómo evoluciona sistemáticamente el modelo de datos de almacén? ¿Necesitamos “reglas del juego” y cuáles podrían ser? ¿Qué nos dará? ¿Y si nos equivocamos con el modelo?
¿Deberíamos guardar los datos, o el historial de sus cambios, si "la empresa no los necesita"? No quisiera "almacenar basura" y complicar el uso de estos datos para tareas reales. ¿Debería la bóveda mantener la historia? ¿A qué se parece? ¿Cómo funciona el almacenamiento a lo largo del tiempo?
¿Deberíamos intentar unificar los datos en el almacenamiento si tenemos un sistema de gestión de datos maestros? Si hay MDM, ¿significa esto que todo el problema con los datos maestros ahora está resuelto?
Se espera que pronto reemplacemos los sistemas de contabilidad clave. ¿Es necesario que el almacén de datos esté listo para cambiar la fuente? ¿Cómo se puede lograr esto?
¿Necesitamos metadatos? ¿Qué queremos decir con esto? ¿Dónde exactamente se pueden usar? ¿Cómo se puede implementar? ¿Necesito guardarlos "en un solo lugar"?
Nuestros clientes son extremadamente inestables en sus requisitos y deseos; algo cambia constantemente. En general, nuestro negocio es muy dinámico. Mientras hacemos algo, ya se vuelve innecesario. ¿Cómo podemos hacerlo de tal manera que obtengamos el resultado lo más rápido posible, como pan caliente?
Los usuarios exigen capacidad de respuesta. Pero no podemos ejecutar nuestros procesos de arranque principales a menudo, porque esto carga los sistemas de origen (tiene un efecto negativo en el rendimiento); por lo tanto, colgamos flujos de datos adicionales, que recogerán puntualmente lo que necesitamos. Es cierto que hay muchas corrientes. Y luego descartaremos algunos de los datos. Además, habrá un problema de convergencia. Pero no hay otra forma ...

Ya han pasado muchas cosas. Pero esta no es una lista completa, es fácil complementarla y desarrollarla. No lo esconderemos en la mesa, sino que lo colgaremos en un lugar visible, manteniendo estos temas en el centro de nuestra atención en el proceso de trabajo.
Nuestra tarea consiste en encontrar una solución integral como resultado.

Antifragilidad

Mirando nuestra lista, se puede sacar una conclusión. No es difícil crear una especie de "base de datos para informar", cargar datos allí o incluso construir algún tipo de proceso de actualización de datos de rutina. El sistema comienza a vivir de alguna manera, aparecen usuarios y con ellos obligaciones y SLA, surgen nuevos requisitos, se conectan fuentes adicionales, cambian las metodologías, todo esto debe tenerse en cuenta en el proceso de desarrollo.

Después de un tiempo, la imagen es la siguiente:
“Aquí está la bóveda. Y funciona si no lo tocas. Los problemas surgen cuando tenemos que cambiar algo ".

Nos llega un cambio, cuya influencia no somos capaces de evaluar y comprender (ya que no pusimos tales herramientas en el sistema desde el principio) - y para no correr riesgos, no tocamos lo que es, pero hacemos una extensión más en el costado, y otra, y también - convirtiendo nuestra decisión en chabolas, o, como dicen en América Latina, "favelas", donde hasta la policía tiene miedo de entrar.
Hay una sensación de pérdida de control sobre el propio sistema, caos. Se necesitan cada vez más manos para mantener los procesos existentes y resolver problemas. Y los cambios son cada vez más difíciles de realizar. En otras palabras, el sistema se vuelve inestable al estrés, inadaptado a los cambios. Y además, existe una fuerte dependencia de personajes que "conocen la calle", ya que nadie tiene un "mapa".

Esta propiedad de un objeto - colapsar bajo la influencia del caos, eventos aleatorios y choques - Nassim Nicholas Taleb llama fragilidad ... Y también introduce el concepto opuesto: antifragilidad – cuando el objeto no colapsa por estrés y accidentes, sino que se beneficia directamente de él... ("Antifragilidad. Cómo beneficiarse del caos")
De lo contrario, se puede llamar adaptabilidad o resiliencia al cambio .

¿Qué significa esto en este contexto? ¿Cuáles son las “fuentes del caos” para los sistemas de TI? ¿Y qué significa "capitalizar el caos" en términos de arquitectura de TI?
El primer pensamiento que me viene a la mente son los cambios que vienen del exterior. ¿Qué es el mundo exterior para el sistema? Para almacenamiento en particular. Por supuesto, en primer lugar, cambios desde el lado de las fuentes de datos para la tienda:

cambiar los formatos de los datos entrantes;
sustitución de algunos sistemas de fuentes de datos por otros;
cambio de reglas / plataformas para la integración de sistemas;
cambiar la interpretación de los datos (los formatos se guardan, la lógica de trabajar con los datos cambia);
cambiar el modelo de datos si la integración se realiza a nivel de datos (analizar los archivos de registro de transacciones de la base de datos);
crecimiento en los volúmenes de datos - si bien no había muchos datos en el sistema de origen y la carga no era alta - era posible recuperarlos en cualquier momento, con una solicitud arbitrariamente pesada, los datos y la carga aumentaron - ahora hay restricciones estrictas ;
etc.

Los propios sistemas de origen, la composición de la información y su estructura, el tipo de interacción de integración, así como la lógica misma de trabajar con datos pueden cambiar. Cada sistema implementa su propio modelo de datos y enfoques para trabajar con ellos, que cumplen con las metas y objetivos del sistema. Y no importa cuánto intenten unificar los modelos de la industria y las prácticas de referencia, inevitablemente surgirán matices. (Y además, el proceso de unificación de la industria en sí, por varias razones, no está progresando mucho).
La cultura de trabajar con datos corporativos: la presencia y el control de la arquitectura de la información, un modelo semántico unificado, los sistemas de gestión de datos maestros (MDM) facilitan un poco la tarea de consolidar los datos en el almacén, pero no excluyen su necesidad.

Los consumidores del almacén inician cambios no menos críticos (cambio de requisitos):

anteriormente, había suficientes datos para crear un informe; ahora era necesario conectar campos adicionales o una nueva fuente de datos;
las técnicas de procesamiento de datos implementadas anteriormente están desactualizadas: debe reelaborar los algoritmos y todo lo que lo afecta;
Anteriormente, todos estaban satisfechos con el valor actual del atributo del diccionario en el panel de información; ahora se requiere el valor que sea relevante en el momento del hecho / evento analizado;
existía un requisito para la profundidad del historial de almacenamiento de datos, que no existía antes, para almacenar datos no durante 2 años, sino durante 10 años;
anteriormente había suficientes datos al "final del día / período"; ahora necesita el estado de los datos "dentro del día", o en el momento de un evento determinado (por ejemplo, tomar una decisión sobre una solicitud de préstamo, por Basilea II);
antes estábamos satisfechos con informar sobre los datos de ayer (T-1) o más tarde, ahora necesitamos T0;
etc.

Tanto las interacciones de integración con los sistemas de origen como los requisitos de los consumidores de los datos del almacén son factores externos para el almacén de datos: algunos sistemas de origen reemplazan a otros, los volúmenes de datos crecen, los formatos de los datos entrantes cambian, los requisitos de los usuarios cambian, etc. Y todos estos son cambios externos típicos para los cuales nuestro sistema, nuestro repositorio, debe estar listo. Con la arquitectura adecuada, no deberían matar el sistema.

Pero eso no es todo.
Hablando de variabilidad, en primer lugar, recordamos los factores externos. Después de todo, por dentro podemos controlarlo todo, nos parece que sí, ¿no? Si y no. Sí, la mayoría de los factores que están fuera de la zona de influencia son externos. Pero también hay "entropía interna". Y precisamente por su presencia, en ocasiones necesitamos volver “al punto 0”. Vuelve a empezar el juego.
En la vida, solemos empezar de cero. ¿Por qué es esto peculiar para nosotros? ¿Y es realmente tan malo?
Aplicado a TI. Para el sistema en sí, esto puede ser muy bueno, la capacidad de repensar las decisiones individuales. Especialmente cuando podemos hacerlo localmente. La refactorización es el proceso de desentrañar la "red" que aparece periódicamente en el proceso de desarrollo del sistema. Volver al principio puede resultar útil. Pero tiene un precio.
Con una gestión de arquitectura competente, este precio disminuye y el proceso de desarrollo del sistema en sí se vuelve más controlable y transparente. Un ejemplo simple: si se observa el principio de modularidad, puede reescribir un módulo separado sin afectar las interfaces externas. Y esto no se puede hacer con una estructura monolítica.

La antifragilidad de un sistema está determinada por la arquitectura que está incrustada en él. Y es esta propiedad la que lo hace adaptable.
Cuando hablamos de arquitectura adaptativa- queremos decir que el sistema es capaz de adaptarse a los cambios, y en absoluto que estemos cambiando constantemente la propia arquitectura. Por el contrario, cuanto más estable y estable sea la arquitectura, menos requisitos que conlleva su revisión, más adaptativo será el sistema.

Las soluciones que implican una revisión de toda la arquitectura tendrán un precio mucho más alto. Y debe tener muy buenas razones para su adopción. Por ejemplo, tal razón fundamental podría ser un requisito que no se puede implementar dentro de la arquitectura existente. Luego dicen: ha aparecido un requisito que afecta a la arquitectura.
Por lo tanto, también necesitamos conocer nuestros "límites de antifragilidad". La arquitectura no se desarrolla "en el vacío", se basa en los requisitos y expectativas actuales. Y si la situación cambia fundamentalmente, debemos comprender que hemos ido más allá de la arquitectura actual, y debemos revisarla, encontrar una solución diferente y pensar en los caminos de la transición.
Por ejemplo, asumimos que siempre necesitaremos datos en el almacenamiento al final del día, tomaremos datos todos los días usando interfaces de sistema estándar (a través de un conjunto de vistas). Luego, desde el departamento de gestión de riesgos surgió la demanda de la necesidad de recibir datos no al final del día, sino en el momento de la decisión sobre el préstamo. No es necesario que intente "tirar de lo que no está tensado", solo debe admitir este hecho, cuanto antes, mejor. Y empezar a trabajar en un enfoque que nos permita solucionar el problema.
Aquí hay una línea muy fina: si tomamos en cuenta solo los "requisitos en el momento" y no miramos varios pasos hacia adelante (y varios años por delante), entonces aumentamos el riesgo de enfrentar un requisito que afecte a la arquitectura demasiado tarde, y el precio de nuestro cambio será muy alto. Mirar un poco hacia adelante, dentro de los límites de nuestro horizonte, no ha hecho daño a nadie todavía.

El ejemplo de un sistema del "cuento de almacenamiento" es solo un ejemplo de un sistema muy inestable construido sobre enfoques de diseño frágiles. Y si esto sucede, la destrucción ocurre con bastante rapidez, para esta clase particular de sistemas.
¿Por qué puedo decir eso? El tema de los repositorios no es nuevo. Los enfoques y prácticas de ingeniería que se han desarrollado durante este tiempo estaban dirigidos precisamente a esto: mantener la viabilidad del sistema.
Un ejemplo simple: una de las razones más comunes del fracaso de los proyectos de almacenamiento de despegue es intentar construir almacenamiento en sistemas de origen en desarrollo sin acordar interfaces de integración, tratando de obtener datos directamente de tablas. Como resultado, entramos en desarrollo, durante este tiempo la base de datos de origen cambió, y los flujos de carga en el repositorio dejaron de funcionar. Es demasiado tarde para rehacer algo. Y si aún no se ha asegurado haciendo varias capas de tablas dentro del almacenamiento, puede tirar todo y comenzar de nuevo. Este es solo un ejemplo, y uno de los más simples.

El criterio de Taleb para frágil y antifrágil es simple. El juez principal es el tiempo. Si el sistema resiste la prueba del tiempo y muestra su "vitalidad" e "indestructibilidad", tiene la propiedad de antifragilidad.
Si, al diseñar un sistema, tenemos en cuenta la antifragilidad como un requisito, esto nos animará a utilizar enfoques para construir su arquitectura que harán que el sistema sea más adaptable tanto al "caos desde el exterior" como al "caos desde dentro". . Y, en última instancia, el sistema tendrá una vida útil más larga.
Ninguno de nosotros quiere hacer "casas improvisadas". Y no te engañes, que no es de otra manera hoy. Es normal que una persona mire algunos pasos hacia adelante en cualquier momento, especialmente durante una crisis.

¿Qué es un almacén de datos y por qué lo estamos construyendo?

El artículo sobre arquitectura de almacenamiento asume que el lector no solo sabe qué es, sino que también tiene cierta experiencia con dichos sistemas. Sin embargo, consideré necesario hacer esto: volver a los orígenes, al comienzo del camino, porque es allí donde se ubica el "fulcro" del desarrollo.

¿Cómo llegó la gente a la idea de que se necesitan almacenes de datos? ¿Y en qué se diferencian de una "base de datos muy grande"?
Hace mucho tiempo, cuando había simplemente "sistemas de procesamiento de datos comerciales" en el mundo, no había una división de los sistemas de TI en clases como sistemas oltp de front-end, sistemas dss de back-office, sistemas de procesamiento de texto, almacenes de datos, etc. .
Fue durante este tiempo que Michael Stonebreaker creó el primer motor de base de datos relacional, Ingres.
Y ese fue el momento en que la era de las computadoras personales irrumpió en la industria de las computadoras como un torbellino y cambió para siempre todas las ideas de la comunidad de TI de esa época.

En ese momento, era fácil encontrar aplicaciones empresariales escritas sobre la base de DBMS de escritorio, como Clipper, dBase y FoxPro. Y el mercado de aplicaciones cliente-servidor y DBMS solo estaba ganando impulso. Los servidores de bases de datos aparecieron uno tras otro, que ocuparán su nicho en el espacio de TI durante mucho tiempo: Oracle, DB2, etc.
Y el término "aplicación de base de datos" ha sido común. ¿Qué incluía dicha aplicación? Simplificado: algunos formularios de entrada a través de los cuales los usuarios podían ingresar información simultáneamente, algunos cálculos que se iniciaron "por botón" o "según lo programado", así como algunos informes que se podían ver en la pantalla o guardar como archivos y enviar para sellar.
“Nada especial, solo una aplicación normal, solo una base de datos”, comentó uno de mis mentores al principio de mi carrera. "¿Así que nada especial?" - Pensé entonces.

Si miras de cerca, todavía hay algunas peculiaridades. A medida que los usuarios crecen, aumenta el volumen de información entrante, a medida que aumenta la carga en el sistema, sus desarrolladores, diseñadores, para mantener el rendimiento a un nivel aceptable, recurren a algunos "trucos". La primera es la división de un "sistema de procesamiento de datos comerciales" monolítico en una aplicación de contabilidad que brinda soporte a los usuarios en línea, y una aplicación separada para el procesamiento por lotes de datos y generación de informes. Cada una de estas aplicaciones tiene su propia base de datos e incluso está alojada en una instancia separada del servidor de la base de datos, con diferentes configuraciones para diferentes tipos de carga: OLTP y DSS. Y los flujos de datos se alinean entre ellos.

Es todo? Parecería que el problema se ha resuelto. ¿Qué pasa después?
Y luego las empresas crecen, sus necesidades de información se multiplican. El número de interacciones con el mundo exterior también está creciendo. Y como resultado, no hay una gran aplicación que automatice completamente todos los procesos, sino varios diferentes de diferentes fabricantes. El número de sistemas que generan información - sistemas de fuentes de datos en la empresa está aumentando. Y, tarde o temprano, será necesario ver y comparar la información recibida de diferentes sistemas. Así es como aparecen los almacenes de datos en la empresa: una nueva clase de sistemas.
La definición generalmente aceptada de esta clase de sistemas es la siguiente.

Almacén de datos (o almacén de datos)- una base de datos de información orientada a temas especialmente diseñada y diseñada para la preparación de informes y análisis de negocios con el fin de apoyar la toma de decisiones en una organización

Por lo tanto, consolidación datos de diferentes sistemas, la capacidad de verlos de cierta manera "uniforme" (unificada): esta es una de las propiedades clave de los sistemas de la clase de almacenes de datos. Esta es la razón por la que han surgido repositorios durante la evolución de los sistemas de TI.

Funciones clave de los almacenes de datos

Miremos más de cerca. ¿Cuáles son las características clave de estos sistemas? ¿Qué diferencia a los almacenes de datos de otros sistemas de TI empresariales?

Primero, se trata de grandes volúmenes. Muy grande. VLDB - así es como los proveedores líderes llaman a estos sistemas cuando dan sus recomendaciones sobre el uso de sus productos. Desde todos los sistemas de la empresa, los datos fluyen hacia esta gran base de datos y se almacenan allí "para siempre y sin cambios", como dicen los libros de texto (en la práctica, la vida se vuelve más complicada).

En segundo lugar, estos son datos históricos: "Memoria corporativa" - los llamados almacenes de datos. En cuanto a trabajar con tiempo en repositorios, todo es bastante interesante. En los sistemas contables, los datos están actualizados en este momento. Luego, el usuario realiza una operación y los datos se actualizan. Al mismo tiempo, es posible que no se guarde el historial de cambios; depende de la práctica contable. Tome el saldo de una cuenta bancaria, por ejemplo. Puede que nos interese el saldo actual en "ahora", al final del día, o en el momento de algún evento (por ejemplo, en el momento de calcular la puntuación). Si bien los dos primeros son bastante fáciles de resolver, el último probablemente requerirá esfuerzos especiales. El usuario, trabajando con el almacenamiento, puede referirse a los períodos pasados, compararlos con el actual, etc. Son estas capacidades relacionadas con el tiempo las que distinguen significativamente los almacenes de datos de los sistemas de contabilidad (obtener el estado de los datos en varios puntos del eje del tiempo) hasta cierta profundidad en el pasado.

Tercero, es consolidación y unificación de datos ... Para que su análisis conjunto sea posible, es necesario llevarlos a una forma común: modelo de datos unificados , compare hechos con libros de referencia unificados. Aquí puede haber varios aspectos y dificultades. En primer lugar - conceptual - bajo el mismo término, diferentes personas de diferentes departamentos pueden entender cosas diferentes. Y viceversa, para llamar a algo de manera diferente, que es esencialmente lo mismo. ¿Cómo proporcionar una “vista única” manteniendo la visión específica de un grupo de usuarios en particular?

Cuarto, este es un trabajo con calidad de los datos ... En el proceso de carga de datos en el almacenamiento, se limpian, se realizan transformaciones generales y transformaciones. Las transformaciones generales deben realizarse en un solo lugar y luego usarse para crear varios informes. Esto evitará las inconsistencias que molestan a los usuarios comerciales, especialmente a los ejecutivos que se sientan a la mesa con números de diferentes departamentos que no coinciden entre sí. La mala calidad de los datos crea errores y discrepancias en los informes, cuya consecuencia es una disminución del nivel confianza del usuario a todo el sistema, a todo el servicio analítico en su conjunto.

Concepto arquitectónico

Cualquiera que haya encontrado un repositorio probablemente haya observado algún tipo de "estructura en capas", ya que es este paradigma arquitectónico el que ha echado raíces para los sistemas de esta clase. Y no es casualidad. Las capas de almacenamiento pueden percibirse como componentes separados del sistema, con sus propias tareas, área de responsabilidad, "reglas del juego".
La arquitectura en capas es un medio para lidiar con la complejidad del sistema: cada nivel subsiguiente se abstrae de las complejidades de la implementación interna del anterior. Este enfoque le permite seleccionar tareas del mismo tipo y resolverlas de manera uniforme, sin tener que reinventar la "rueda" desde cero cada vez.
El diagrama arquitectónico conceptual se muestra esquemáticamente en la figura. Este es un diagrama simplificado que refleja solo la idea clave: el concepto, pero sin los "detalles anatómicos" que surgirían con una elaboración más profunda de los detalles.

Como se muestra en el diagrama, seleccione conceptualmente las siguientes capas. Las tres capas principales que contienen el área de almacenamiento de datos (indicado por el rectángulo relleno) y el software de carga de datos (indicado convencionalmente por las flechas del mismo color). Y también una capa de servicios auxiliares, que, sin embargo, juega un papel de conexión muy importante: la gestión de la carga de datos y el control de calidad.

Capa de datos primaria: capa de datos primaria (o puesta en escena , o capa operativa ) - diseñado para cargar desde sistemas de origen y guardar información primaria, sin transformaciones - en calidad original y soporte para un historial completo de cambios.
La tarea de esta capa- abstraer las capas posteriores de almacenamiento de la estructura física de las fuentes de datos, los métodos de recopilación de datos y los métodos para separar el delta de cambios.

Capa de datos central: almacenamiento central - el componente central del sistema que distingue el almacenamiento de una "plataforma de integración por lotes" o "volcado de big data", ya que su función principal es consolidación de datos de diferentes fuentes, reducción a estructuras uniformes, claves. Es al cargar en el kernel que el trabajo principal se realiza con la calidad de los datos y las transformaciones generales, que pueden ser bastante complejas.
La tarea de esta capa- abstraer a sus consumidores de las características del dispositivo lógico de las fuentes de datos y de la necesidad de comparar datos de diferentes sistemas, para garantizar la integridad y calidad de los datos.

Capa de Data Mart: vitrinas analíticas - un componente cuya función principal es convertir datos en estructuras que sean convenientes para el análisis (si BI funciona con vitrinas, esto es, por regla general, un modelo dimensional), o de acuerdo con los requisitos del sistema de consumo.
Como regla general, los data marts toman datos del núcleo, como una fuente confiable y verificada, es decir, utilice el servicio de este componente para traer datos a un solo formulario. Llamaremos a tales vitrinas regular ... En algunos casos, los escaparates pueden tomar datos directamente de la puesta en escena, operando con datos primarios (en las claves de origen). Este enfoque se usa generalmente para tareas locales donde no se requiere la consolidación de datos de diferentes sistemas y donde se necesita más eficiencia que calidad de datos. Tales vitrinas se llaman operando ... Algunos indicadores analíticos pueden tener métodos de cálculo muy complejos. Por lo tanto, para tales cálculos y transformaciones no triviales, el llamado vitrinas secundarias .
Tarea de capa de escaparate- preparación de datos de acuerdo con los requisitos de un consumidor específico: una plataforma de BI, un grupo de usuarios o un sistema externo.

Las capas descritas anteriormente consisten en un área de almacenamiento de datos persistentes, así como un módulo de software para cargar y transformar datos. Esta división en capas y regiones es lógica. Físicamente, la implementación de estos componentes puede ser diferente; incluso puede usar diferentes plataformas para almacenar o transformar datos en diferentes capas, si esto es más eficiente.
Las áreas de almacenamiento contienen técnicas (tablas de búfer) que se utilizan en el proceso de transformación de datos y tablas de destino al que se refiere el componente consumidor. Es una buena práctica "cubrir" las tablas de destino con vistas. Esto facilita el posterior mantenimiento y desarrollo del sistema. Los datos de las tablas de destino de las tres capas están marcados con campos técnicos especiales (metaatributos), que se utilizan para respaldar los procesos de carga de datos, así como para permitir la auditoría informativa de los flujos de datos en el almacén.

Además, se distingue un componente especial (o un conjunto de componentes), que proporciona funciones de servicio para todas las capas. Una de sus tareas clave es la función de control - proporcionar "reglas de juego uniformes" para todo el sistema en su conjunto, dejando el derecho de utilizar varias opciones para implementar cada una de las capas descritas anteriormente - incl. utilizar diferentes tecnologías para cargar y procesar datos, diferentes plataformas de almacenamiento, etc. Vamos a llamarlo capa de servicio ... No contiene datos comerciales, pero tiene sus propias estructuras de almacenamiento: contiene un área de metadatos, así como un área para trabajar con la calidad de los datos (y posiblemente otras estructuras, según las funciones que se le asignen).

Una división tan clara del sistema en componentes separados aumenta significativamente la capacidad de control del desarrollo del sistema:

la complejidad de la tarea que se le plantea al desarrollador de la funcionalidad de este o aquel componente se reduce (no debe resolver simultáneamente los problemas de integración con sistemas externos, y pensar en los procedimientos de limpieza de datos, y pensar en la presentación óptima de los datos para los consumidores): la tarea es más fácil de descomponer, evaluar y realizar una pequeña entrega;
puede conectarse con el trabajo de varios artistas (e incluso equipos o contratistas), porque este enfoque le permite paralelizar eficazmente las tareas, reduciendo su influencia mutua entre sí;
la presencia de la puesta en escena persistente le permite conectar rápidamente fuentes de datos sin diseñar todo el núcleo o escaparates para toda el área temática, y luego gradualmente terminar de construir las capas restantes de acuerdo con las prioridades (además, los datos ya estarán en el almacenamiento, disponibles para analistas de sistemas, lo que facilitará enormemente las tareas del desarrollo posterior del almacenamiento);
la presencia de un núcleo permite que todo el trabajo con calidad de datos (así como posibles errores y errores) se oculte de los escaparates y del usuario final, y lo más importante: al utilizar este componente como una única fuente de datos para los escaparates, puede evitar los datos problemas de convergencia debido a la implementación de algoritmos comunes en un solo lugar;
destacar marts le permite tener en cuenta las diferencias y los detalles de la comprensión de los datos que pueden tener los usuarios de diferentes departamentos, y su diseño para los requisitos de BI permite no solo emitir cifras agregadas, sino garantizar la validación de los datos al brindar oportunidades para desglosar a indicadores primarios;
la presencia de una capa de servicio le permite realizar análisis de datos de un extremo a otro (linaje de datos), usar herramientas de auditoría de datos unificadas, enfoques generales para resaltar cambios delta, trabajar con la calidad de los datos, herramientas de administración de carga, monitoreo y diagnóstico de errores, y acelerar la resolución de problemas.

Este enfoque de la descomposición también hace que el sistema sea más resistente al cambio (en comparación con la "estructura monolítica") - asegura su antifragilidad:

los cambios por parte de los sistemas fuente se procesan en la etapa de preparación: en el kernel, solo se modifican los flujos que están influenciados por estas tablas de preparación, el efecto en los escaparates es mínimo o está ausente;
Los cambios en los requisitos por parte de los consumidores se procesan en su mayor parte en los escaparates (si esto no requiere información adicional que aún no se encuentra en la tienda).

A continuación, repasaremos cada uno de los componentes presentados anteriormente y los veremos con un poco más de detalle.

Núcleo del sistema

Comencemos desde el medio: el núcleo del sistema o la capa intermedia. Está etiquetado como Capa central. El kernel desempeña el papel de consolidación de datos: lleva a estructuras uniformes, libros de referencia, claves. Aquí es donde se lleva a cabo el trabajo principal con la calidad de los datos: limpieza, transformación, unificación.

La presencia de este componente le permite reutilizar flujos de datos que transforman los datos primarios recibidos de los sistemas de origen en un determinado formato unificado, siguiendo reglas y algoritmos generales, y no repetir la implementación de la misma funcionalidad por separado para cada escaparate de la aplicación, lo cual, en Además de un uso ineficiente de los recursos, puede conllevar también discrepancias en los datos.
El núcleo del repositorio se implementa en un modelo de datos, en el caso general, diferente tanto de los modelos de sistemas fuente, como de los formatos y estructuras de los consumidores.

Modelo básico de almacén y modelo de datos empresariales

La principal preocupación de la capa de almacenamiento intermedia es la estabilidad. Es por eso que el enfoque principal aquí está en el modelo de datos. Se le conoce comúnmente como el "modelo de datos corporativos". Lamentablemente, a su alrededor se ha formado una especie de aura de mitos y absurdos, que a veces llevan a negarse a construirlo por completo, pero en vano.

Mito 1. Un modelo de datos empresarial es un modelo enorme con miles de entidades (tablas).
Realmente. En cualquier área temática, en cualquier dominio empresarial, en los datos de cualquier empresa, incluso la más compleja, hay pocas entidades básicas: 20-30.

Mito 2. No es necesario desarrollar ningún "modelo propio" - compramos un modelo de referencia de la industria - y hacemos todo de acuerdo con él. Gastamos dinero, pero obtenemos un resultado garantizado.
Realmente. Los modelos de referencia pueden resultar muy útiles porque contener experiencia de la industria en el modelado de esta área. De ellos puede extraer ideas, enfoques, prácticas de nomenclatura. Compruebe la "profundidad de cobertura" del área para que no se pase por alto algo importante. Pero es poco probable que podamos utilizar un modelo de este tipo de fábrica, tal como está. Este es el mismo mito que, por ejemplo, la compra de un sistema ERP (o CRM) y su implementación sin ningún "endurecimiento". El valor de estos modelos nace de su adaptación a las realidades de este negocio en particular, de esta empresa en particular.

Mito 3. El desarrollo de un modelo de repositorio central puede llevar muchos meses, durante los cuales el proyecto se congelará. Además, requiere una gran cantidad de reuniones y mucha gente.
Realmente. El modelo de repositorio se puede desarrollar con el repositorio de forma iterativa, pieza por pieza. Para áreas descubiertas, se establecen "puntos de expansión" o "stubs". se aplican algunos "diseños universales". Al mismo tiempo, necesita saber cuándo detenerse para no obtener una cosa súper universal de 4 tablas, en la que es difícil "poner datos" y (aún más difícil) obtenerlos. Y que es extremadamente subóptimo en términos de rendimiento.

Realmente lleva tiempo desarrollar el modelo. Pero este no es el tiempo dedicado a "dibujar entidades", es el tiempo necesario para analizar el área temática y comprender cómo se organizan los datos. Es por eso que los analistas están muy involucrados en este proceso, y también participan varios expertos en negocios. Y esto se hace puntualmente, de forma selectiva. Y no organizando reuniones con la participación de un número insano de personas, enviando enormes cuestionarios, etc.
Un buen análisis de sistemas y negocios es clave para construir un modelo de almacén central. Hay mucho que entender: dónde (en qué sistemas) se generan los datos, cómo funcionan, en qué procesos comerciales circulan, etc. El análisis cualitativo nunca ha dañado un solo sistema. Más bien, por el contrario, los problemas surgen de "puntos blancos" en nuestro entendimiento.

Desarrollar un modelo de datos no es un proceso de inventar e inventar algo nuevo. De hecho, el modelo de datos ya existe en la empresa. Y el proceso de diseño se parece más a una "excavación". El modelo se extrae cuidadosa y cuidadosamente del "suelo" de los datos corporativos y se coloca en una forma estructurada.

Mito 4. Nuestro negocio es tan dinámico en nuestra empresa, y todo está cambiando tan rápido que es inútil para nosotros hacer un modelo; se volverá obsoleto antes de que pongamos en funcionamiento esta parte del sistema.
Realmente. Recuerde que el factor central es la estabilidad. Y sobre todo, la topología del modelo. ¿Por qué? Porque es este componente el que es central e influye en todo lo demás. La estabilidad también es un requisito para el modelo de kernel. Si un modelo se vuelve obsoleto demasiado rápido, entonces está diseñado incorrectamente. Se eligieron enfoques y "reglas del juego" incorrectos para su desarrollo. Y también es una cuestión de análisis cualitativo. Las entidades clave del modelo corporativo rara vez cambian.
Pero si se nos ocurre hacer para una empresa que venda, digamos, confitería, en lugar del directorio de “Productos”, haga “Dulces”, “Tartas” y “Tartas”. Luego, cuando la pizza aparezca en la lista de productos, sí, deberá ingresar muchas mesas nuevas. Y esto es solo una cuestión de enfoque.

Mito 5. La creación de un modelo corporativo es un negocio muy serio, complejo y responsable. Y da miedo cometer un error.
Realmente. El modelo central, aunque debería ser estable, todavía no está “fundido en metal”. Como cualquier otra solución de diseño, su estructura se puede revisar y modificar. Simplemente no necesita olvidarse de esta cualidad. Pero esto no significa en absoluto que “no se pueda respirar”. Y esto no significa que las soluciones temporales y los "talones" que deberían planificarse para el reciclaje sean inaceptables.

Mito 6. Si nuestra fuente de datos es, por ejemplo, un sistema de datos de referencia (o un sistema de gestión de datos maestros - MDM), entonces ya debería corresponder al modelo corporativo de manera amistosa (especialmente si fue diseñado recientemente y no tuvo tiempo para adquirir un "lado", "tradiciones" y cabañas temporales). Resulta que para este caso, ¿no necesitamos un modelo de kernel?
Realmente. Sí, en este caso, la construcción del modelo central del repositorio se facilita enormemente, ya que Seguimos un modelo conceptual de alto nivel ya hecho. Pero no está excluido en absoluto. ¿Por qué? Porque al construir un modelo de un determinado sistema, se aplican algunas de sus propias reglas: qué tipos de tablas usar (para cada entidad), cómo versionar los datos, con qué granularidad mantener el historial, qué meta-atributos (campos técnicos utilizar), etc.

Además, no importa cuán maravilloso y completo sistema de datos de referencia y MDM tengamos, por regla general, habrá matices asociados con la existencia de directorios locales "casi iguales" en otros sistemas de contabilidad. Y este problema, lo queramos o no, tendrá que resolverse en el repositorio; después de todo, aquí se recopilan informes y análisis.

Capa de datos primaria (o capa operativa o de ensayo historizada)

En él se designa como capa de datos primaria. El papel de este componente: integración con sistemas fuente, carga y almacenamiento de datos primarios, así como limpieza preliminar de datos - verificación del cumplimiento de las reglas de control lógico de formato, fijadas en el "acuerdo de interfaz de interacción" con la fuente.
Además, este componente resuelve un problema muy importante para el repositorio: asignar el "verdadero delta de cambios", independientemente de si la fuente le permite rastrear cambios en los datos o no y cómo (con qué criterio se pueden "capturar" ). Tan pronto como los datos se pusieron en fase de preparación, para todas las demás capas, el problema de la asignación delta ya está claro, gracias al etiquetado con metaatributos.

Los datos de esta capa se almacenan en estructuras lo más cerca posible del sistema de origen, para preservar los datos primarios lo más cerca posible de su forma original. Otro nombre para este componente es "capa operativa".
¿Por qué no utilizar simplemente el término bien establecido "puesta en escena"? El hecho es que antes, antes de la "era de los macrodatos y VLDB", el espacio en disco era muy caro y, a menudo, los datos primarios, si se conservaban, eran solo por un período de tiempo limitado. Y a menudo el nombre "puesta en escena" se llama lavable buffer.
Ahora las tecnologías han dado un paso adelante, y podemos permitirnos no solo almacenar todos los datos primarios, sino también historizarlos con el grado de granularidad posible. Esto no significa que no debamos controlar el crecimiento de los datos y no elimina la necesidad de administrar el ciclo de vida de la información, optimizando el costo del almacenamiento de datos, dependiendo de la "temperatura" de uso, es decir. llevar "datos fríos" que tienen menos demanda a medios y plataformas de almacenamiento más baratos.

¿Qué nos aporta la presencia de la "puesta en escena historizada":

la posibilidad de cometer errores (en estructuras, en algoritmos de transformación, en la granularidad del historial) - habiendo histórico completamente los datos primarios en la zona de disponibilidad para el almacenamiento, siempre podemos recargar nuestras tablas;
una oportunidad para pensar: podemos tomarnos nuestro tiempo para elaborar un gran fragmento del kernel en esta iteración particular del desarrollo de almacenamiento, ya que en nuestra puesta en escena, en todo caso, habrá, y con un horizonte temporal parejo (habrá un punto de "referencia histórica");
la posibilidad de análisis (guardaremos incluso aquellos datos que ya no están en la fuente) podrían sobrescribirse allí, ir al archivo, etc. - con nosotros, siguen estando disponibles para su análisis;
la posibilidad de auditoría de información: gracias a la información primaria más detallada, podemos averiguar cómo funcionó la descarga para nosotros, que terminamos con tales cifras (para esto, también necesitamos tener marcado con meta atributos y los metadatos correspondientes en el que funciona la descarga, esto lo decide la capa de servicio).

Qué dificultades pueden surgir a la hora de construir una "puesta en escena historizada":

Sería conveniente establecer requisitos para la integridad transaccional de esta capa, pero la práctica muestra que esto es difícil de lograr (esto significa que en esta área no garantizamos la integridad referencial de las tablas padre e hijo); la alineación de integridad se produce en las siguientes capas;
esta capa contiene volúmenes muy grandes (los más voluminosos en el almacenamiento, a pesar de toda la redundancia de las estructuras analíticas), y debe poder manejar dichos volúmenes, tanto en términos de carga como en términos de solicitudes (de lo contrario, puede en serio degradar el rendimiento de todo el almacenamiento).

¿Qué más es interesante decir sobre esta capa?
En primer lugar, si nos alejamos del paradigma de los “procesos de carga de punta a punta”, entonces la regla “la caravana se mueve a la velocidad del último camello” ya no nos sirve, más precisamente, abandonamos la “caravana”. y cambiamos al principio de "transportador": tomamos los datos de la fuente, los colocamos en su capa, listos para tomar la siguiente porción. Esto significa que
1) no esperamos a que suceda el procesamiento en otras capas;
2) no dependemos del cronograma para el suministro de datos por otros sistemas.
En pocas palabras, programamos un proceso de carga que toma datos de una fuente a través de una forma específica de conectarse a ella, verifica, extrae el delta y coloca los datos en tablas de preparación de destino. Y eso es todo.

En segundo lugar, estos procesos, como puede ver, son muy simples, se podría decir trivialmente, desde el punto de vista de la lógica. Esto significa que se pueden optimizar y parametrizar muy bien, reduciendo la carga en nuestro sistema y acelerando el proceso de conexión de fuentes (tiempo de desarrollo).
Para que esto suceda, necesita conocer muy bien las peculiaridades de las características tecnológicas de la plataforma en la que trabaja este componente, y luego puede hacer una herramienta muy efectiva.

Capa de escaparate

La capa de Data Mart es responsable de preparar y proporcionar datos a los usuarios finales: personas o sistemas. En este nivel, los requisitos del consumidor se tienen en cuenta tanto como sea posible, tanto lógicos (conceptuales) como físicos. El servicio debe proporcionar exactamente lo que se necesita, ni más ni menos.

Si el consumidor es un sistema externo, entonces, por regla general, dicta las estructuras de datos que necesita y las reglas para la recopilación de información. Un buen enfoque es aquel en el que el consumidor es responsable de la correcta recopilación de datos. El data warehouse preparado, formó un escaparate, brindó la posibilidad de recopilación incremental de datos (marcando con meta-atributos para el posterior resaltado del delta de cambios), y el sistema consumidor entonces mismo controla y es responsable de cómo utiliza este escaparate. Pero hay algunas peculiaridades: cuando el sistema no tiene un componente activo para la recolección de datos - o se necesita un componente externo que realizará la función integradora, o el almacenamiento actuará como una "plataforma de integración" - y asegurará el correcto incremento carga de datos más allá - fuera del almacenamiento. Aquí surgen muchos matices, y ambas partes deben pensar y comprender las reglas de la interacción de la interfaz (sin embargo, como siempre, en lo que respecta a la integración). Como regla general, se aplica la limpieza / archivo de datos de rutina a dichos mercados de datos (rara vez es necesario que estos "datos de tránsito" se almacenen durante mucho tiempo).

Lo más importante desde el punto de vista de las tareas analíticas son las vitrinas "para las personas", más precisamente, para las herramientas de BI con las que trabajan.
Sin embargo, existe una categoría de "usuarios especialmente avanzados" - analistas, investigadores de datos - que no necesitan herramientas de BI o procesos regulatorios para llenar sistemas externos especializados. Necesitan algún tipo de "escaparates comunes" y "su propia caja de arena", donde puedan crear tablas y transformaciones a su discreción. En este caso, la responsabilidad del repositorio es asegurarse de que estos escaparates comunes estén llenos de datos de acuerdo con las regulaciones.
Por separado, podemos destacar a los consumidores como las herramientas de minería de datos: análisis profundo de datos. Estas herramientas tienen sus propios requisitos de preparación de datos y los científicos de datos también trabajan con ellas. Para el almacenamiento, la tarea se reduce a - nuevamente, apoyar el servicio para cargar algunos escaparates del formato acordado.

Sin embargo, volvamos a las vitrinas analíticas. Estos son los que son de interés desde el punto de vista de los diseñadores de almacenamiento en esta capa de datos.
En mi opinión, el mejor enfoque probado en el tiempo para diseñar data marts, al que casi todas las plataformas de BI ahora están "afiladas", es el enfoque de Ralph Kimball. Es conocido como modelado dimensional - modelado multidimensional. Hay muchas publicaciones sobre este tema. Por ejemplo, las reglas básicas se pueden encontrar en la publicación. Y, por supuesto, puede recomendarlo al gurú del modelado multidimensional. Otro recurso útil son los consejos de Kimball
El enfoque multidimensional para la creación de escaparates se describe y trabaja tan bien, tanto por los "evangelistas del método" como por los principales proveedores de software, que no tiene sentido detenerse en él con cierto detalle aquí; siempre es preferible la fuente original. .

Me gustaría hacer un solo énfasis. "Informes y análisis" es diferente. Hay "informes intensos": informes preordenados que se generan en forma de archivos y se entregan a los usuarios a través de los canales de entrega proporcionados. Y luego están los paneles de control: paneles de BI. En esencia, se trata de aplicaciones web. Y el tiempo de respuesta de estas aplicaciones es el mismo que para cualquier otra aplicación web. Esto significa que el tiempo normal para que un BI Panel se actualice es de segundos, no de minutos. Es importante tener esto en cuenta al diseñar su solución. ¿Cómo se puede lograr esto? El método de optimización estándar: miramos de qué se compone el tiempo de respuesta y en qué podemos influir. ¿Cuál es la mayor cantidad de tiempo perdido? Para lecturas de bases de datos físicas (disco), para transmisión de datos a través de la red. ¿Cómo reducir la cantidad de datos leídos y transmitidos en una sola solicitud? La respuesta es obvia y simple: debe agregar los datos o aplicar un filtro a las tablas grandes de las tablas reales que participan en la consulta y excluir la unión de tablas grandes (las referencias a tablas de hechos solo deben pasar por dimensiones).

¿Para qué sirve la BI? ¿Cómo es conveniente? ¿Por qué es eficaz el modelo multidimensional?
BI permite al usuario ejecutar lo que se denomina consultas ad hoc. ¿Qué significa? Esto significa que no conocemos la solicitud exacta de antemano, pero sabemos qué indicadores en qué aspectos puede solicitar el usuario. El usuario genera dicha consulta seleccionando los filtros de BI apropiados. Y la tarea del desarrollador de BI y del diseñador de escaparates es proporcionar esa lógica de la aplicación para que los datos se filtren o se agreguen, evitando una situación en la que se soliciten demasiados datos y la aplicación se "cuelgue". Por lo general, comienzan con números agregados, luego profundizan en datos más detallados, pero a lo largo del camino, instalan los filtros necesarios.

No siempre es suficiente simplemente construir la "estrella correcta" y obtener una estructura conveniente para BI. A veces, necesitará aplicar la desnormalización en algún lugar (mientras mira hacia atrás en cómo esto afectará la carga) y en algún lugar para hacer escaparates y agregados secundarios. Agregue índices o proyecciones en algún lugar (según el DBMS).

Así, mediante "prueba y error", se puede obtener una estructura óptima para BI, que tendrá en cuenta las peculiaridades tanto del DBMS como de la plataforma BI, así como los requisitos del usuario para la presentación de datos.
Si tomamos los datos del "núcleo", entonces dicho procesamiento de escaparates será de naturaleza local, sin afectar de ninguna manera el procesamiento complejo de los datos primarios obtenidos directamente de los sistemas de origen; solo "cambiamos" los datos a un formato conveniente para BI. Y podemos permitirnos hacer esto muchas veces, de diferentes maneras, de acuerdo con diferentes requisitos. Es mucho más fácil y rápido hacer esto en los datos del kernel que recolectar de los "primarios" (cuya estructura y reglas, como sabemos, también pueden "flotar").

Capa de servicio

La capa de servicio es responsable de la implementación de funciones generales (de servicio) que se pueden usar para procesar datos en varias capas de almacenamiento: administración de carga, administración de calidad de datos, diagnóstico de problemas y herramientas de monitoreo, etc.
La presencia de este nivel proporciona transparencia y flujos de datos estructurados en el almacenamiento.

Esta capa incluye dos áreas de almacenamiento de datos:

área de metadatos: se utiliza para el mecanismo de control de carga de datos;
Área de calidad de datos: para la implementación de controles de calidad de datos fuera de línea (es decir, aquellos que no están directamente integrados en los procesos ETL).

Puede organizar el proceso de gestión de descargas de diferentes formas. Un posible enfoque es el siguiente: dividimos todo el conjunto de tablas de almacenamiento en módulos. El módulo puede incluir tablas de una sola capa. Las tablas incluidas en cada módulo se cargan en un proceso separado. Vamos a llamarlo proceso de control ... El inicio del proceso de control se establece en su propio horario. El proceso de control organiza las llamadas a los procesos atómicos, cada uno de los cuales carga una tabla de destino y también contiene algunos pasos generales.
Obviamente, basta con dividir las tablas de preparación en módulos, por sistemas de origen o, más bien, por sus puntos de conexión. Pero para el kernel, esto ya es más difícil de hacer. allí debemos garantizar la integridad de los datos, lo que significa que debemos tener en cuenta las dependencias. Aquellos. Habrá colisiones que deberán resolverse. Y existen diferentes métodos para resolverlos.

Un punto importante en la gestión de la carga es desarrollar un enfoque coherente para el manejo de errores. Los errores se clasifican según su nivel de gravedad. Cuando ocurre un error crítico, el proceso debe detenerse, y tan pronto como sea posible, porque su ocurrencia indica un problema significativo que puede conducir a la corrupción de datos en el almacenamiento. Por lo tanto, la gestión de carga no se trata solo de iniciar procesos, sino también de detenerlos, así como de prevenir el inicio intempestivo (por error).

Para el funcionamiento de la capa de servicio, se crea una estructura de metadatos especial. Esta área almacenará información sobre procesos de carga, conjuntos de datos cargados, puntos de control que se utilizan para mantener un incremento (qué proceso ha leído hasta qué punto) y otra información de servicio necesaria para el funcionamiento del sistema.
Es importante tener en cuenta que todas las tablas de destino en todas las capas están marcadas con un conjunto especial de metacampos, uno de los cuales es el identificador del proceso que actualizó esta fila. Para las tablas dentro de un repositorio, este marcado de proceso permite una forma coherente de resaltar posteriormente el delta de cambios. Cuando se cargan datos en la capa de datos primaria, la situación es más complicada: el algoritmo de asignación delta para diferentes objetos cargados puede ser diferente. Pero la lógica de procesar los cambios aceptados y su incorporación a las tablas de destino para el núcleo y los escaparates es mucho más complicada que para la puesta en escena, donde todo es bastante trivial: es fácil parametrizar y pensar en pasos (procedimientos) estándar reutilizables.

No estoy estableciendo la tarea aquí para cubrir completamente este tema, organizar la descarga, solo resalto los acentos a los que vale la pena prestar atención.
Este enfoque es solo una de las opciones. Es bastante receptivo. Y su "prototipo conceptual" fue el transportador Toyota y el sistema just-in-time. Aquellos. aquí nos estamos alejando del paradigma generalizado de la "descarga de datos exclusivamente nocturna", y descargamos en pequeñas porciones durante el día, tan pronto como los datos están listos en varias fuentes: lo que vino, se descargó. Al mismo tiempo, tenemos muchos procesos paralelos en ejecución. Y la "cola caliente" de datos nuevos "parpadeará" constantemente, e incluso se igualará con el tiempo. Debemos tener en cuenta tal característica. Y, si es necesario, cree vitrinas personalizadas con "cortes", donde todo ya es holístico. Aquellos. es imposible lograr tanto la eficiencia como la coherencia (integridad) al mismo tiempo. Necesitamos un equilibrio: en algún lugar, una cosa es importante, en otro lugar.

Es imperativo proporcionar instalaciones de registro y monitoreo. Es una buena práctica usar eventos escritos, donde puede establecer diferentes parámetros y personalizar el sistema de notificación, suscribiéndose a ciertos eventos. Porque Es muy importante que cuando se requiera la intervención del administrador del sistema, este lo sepa lo antes posible y reciba toda la información de diagnóstico necesaria. Los registros también se pueden utilizar para analizar problemas post-facto, así como para investigar incidentes de mal funcionamiento del sistema, incl. calidad de los datos.

Diseño y mantenimiento de modelos de datos de almacén

¿Por qué es importante prestar atención al diseño de modelos de datos cuando se desarrolla cualquier sistema en el que interviene una base de datos (y especialmente en un almacén)? ¿Por qué no lanzar un conjunto de tablas en cualquier lugar, incluso en un editor de texto? ¿Por qué necesitamos "estas imágenes"?
Curiosamente, incluso los desarrolladores experimentados hacen estas preguntas.
En realidad, sí, nada le impide dibujar tablas y comenzar a usarlas. Si ... si al mismo tiempo en la cabeza (!) El desarrollador tiene una imagen general coherente de la estructura que está esculpiendo. ¿Y si hay varios desarrolladores? ¿Qué pasa si alguien más está usando estas tablas? ¿Y si pasa el tiempo, una persona abandona esta área y luego regresa a ella nuevamente?

¿Puedes resolverlo sin un modelo? En principio, puedes. Y para averiguarlo, y "descifrar las imágenes en una hoja de papel", y "limpiar, asentar" los datos. Pero es mucho más fácil, claro y rápido usar un artefacto ya hecho: un modelo de datos. Y también comprender la "lógica de su dispositivo", es decir. Sería bueno tener reglas generales del juego.

Y lo más importante ni siquiera es eso. Lo más importante es que al diseñar un modelo, nos vemos obligados (¡simplemente sin opciones!) A estudiar el área temática más de cerca y en profundidad, las características del dispositivo de datos y su uso en varios casos de negocios. Y esas preguntas que fácilmente hubiéramos "dejado de lado" por complejas, "difuminadas" lanzando nuestros carteles, sin tratar de precisar diseño modelo - nos veremos obligados a entregar y decidir ahora, al analizar y diseñar, y no más tarde - cuando crearemos informes y pensaremos en “cómo reducir lo incompatible” y “reinventar la rueda” cada vez.

Este enfoque es una de esas prácticas de ingeniería que le permite crear sistemas antifrágiles. Dado que están claramente organizados, son transparentes, convenientes para el desarrollo y también sus "límites de fragilidad" son inmediatamente visibles, puede estimar con mayor precisión la "escala del desastre" cuando aparecen nuevos requisitos y el tiempo requerido para el rediseño (si es necesario).
Por tanto, el modelo de datos es uno de los principales artefactos que se deben mantener durante el desarrollo del sistema. De manera amistosa, debe estar "sobre la mesa" de cada analista, desarrollador, etc. - todos los que participan en proyectos de desarrollo de sistemas.

El diseño de modelos de datos es un tema amplio e independiente. Hay dos enfoques principales para el diseño de almacenamiento.
El enfoque funciona bien para el kernel. Relación entre entidades - cuando se construye un modelo normalizado (3NF) sobre la base del estudio del área temática, más precisamente, su área seleccionada. El mismo "modelo corporativo" que se discutió anteriormente está en juego aquí.

Al diseñar vitrinas, es adecuado modelo multidimensional ... Este enfoque encaja bien con la comprensión de los usuarios comerciales, porque es un modelo que es simple y conveniente para la percepción humana - las personas operan con conceptos comprensibles y familiares de métricas (indicadores) y secciones por las cuales son analizadas. Y esto le permite construir de manera simple y clara el proceso de recopilación de requisitos: dibujamos un conjunto de "matrices de secciones e indicadores", comunicándonos con representantes de varios departamentos. Y luego lo reunimos en una estructura: el "modelo de análisis": formamos el "bus de medición" y definimos los hechos que se definen en ellos. En el camino, estamos trabajando en jerarquías y reglas de agregación.

Entonces es muy fácil pasar al modelo físico, agregando elementos de optimización teniendo en cuenta las peculiaridades del DBMS. Por ejemplo, para Oracle sería particionado, un conjunto de índices, etc. Para Vertica, se utilizarán otras técnicas: clasificación, segmentación, seccionamiento.
Además, es posible que se requiera una desnormalización especial, cuando introducimos deliberadamente redundancia en los datos, gracias a lo cual mejoramos el rendimiento de la consulta, pero al mismo tiempo complicamos la actualización de los datos (ya que la redundancia deberá tenerse en cuenta y mantenerse durante la carga de datos proceso). Quizás, con el fin de mejorar el rendimiento, también tendremos que crear tablas agregadas adicionales, o utilizar características DBMS adicionales como proyecciones en Vertica.

Entonces, al modelar los datos del almacén, en realidad resolvemos varios problemas:

la tarea de construir un modelo conceptual (lógico) del kernel - análisis de sistemas y negocios - investigando el área temática, entrando en detalles y teniendo en cuenta los matices de los "datos en vivo" y su uso en los negocios;
la tarea de construir un modelo de análisis - y luego un modelo de escaparate conceptual (lógico);
la tarea de construir modelos físicos - gestión de redundancia de datos, optimización teniendo en cuenta las peculiaridades del DBMS para consultas y carga de datos.

Al desarrollar modelos conceptuales, es posible que no tengamos en cuenta las peculiaridades de un DBMS en particular, para el cual estamos diseñando una estructura de base de datos. Además, podemos usar un modelo conceptual para crear varios físicos, para diferentes DBMS.

Resumamos.

Un modelo de datos no es una colección de "imágenes bonitas" y el proceso de diseñarlo no es un proceso de dibujarlas. El modelo refleja nuestra comprensión del dominio. Y el proceso de compilarlo es el proceso de estudiarlo e investigarlo. Este es un tiempo perdido. Y para nada "dibujar y pintar".
Un modelo de datos es un artefacto de diseño, una forma de intercambiar información de forma estructurada entre los miembros del equipo. Para hacer esto, debe estar claro para todos (esto se proporciona mediante notación y explicación) y disponible (publicado).
El modelo de datos no se crea una vez y se congela, sino que se crea y desarrolla en el proceso de desarrollo del sistema. Nosotros mismos fijamos las reglas para su desarrollo. Y podemos cambiarlos si vemos cómo hacerlo mejor, más fácil y más eficientemente.
El modelo de datos (físico) le permite consolidar y aprovechar un conjunto de mejores prácticas destinadas a la optimización, es decir, utilice las técnicas que ya han funcionado para este DBMS.

Características de los proyectos de almacenamiento de datos

Detengámonos en los detalles de los proyectos en cuyo marco la empresa construye y desarrolla almacenes de datos. Y veámoslos desde el punto de vista de la influencia del aspecto arquitectónico. ¿Por qué es importante para este tipo de proyectos construir una arquitectura, y desde el principio? Y es la presencia de una arquitectura bien pensada lo que le da flexibilidad al proyecto del almacén de datos, le permite distribuir el trabajo de manera eficiente entre los ejecutantes y también hace que sea más fácil predecir el resultado y hacer que el proceso sea más predecible.

El almacén de datos es un software personalizado

Un almacén de datos es siempre un "desarrollo personalizado", no una solución en caja. Sí, existen aplicaciones de BI específicas de la industria que incluyen un modelo de datos de referencia, procesos ETL preconfigurados de fuentes comunes (por ejemplo, sistemas ERP), un conjunto de informes y paneles de BI estándar. Pero en la práctica, el almacenamiento rara vez se implementa, como una "caja". He trabajado con repositorios durante unos 10 años y nunca había visto una historia así. Siempre hay algunos matices asociados con las características únicas de la empresa, tanto del panorama empresarial como de TI. Por lo tanto, esperar que la arquitectura la proporcione el "proveedor" que suministra la solución es algo imprudente. La arquitectura de tales sistemas a menudo "madura" dentro de la propia organización. O está formado por los especialistas de la empresa contratista, que es la principal ejecutora del proyecto.

El almacén de datos es un proyecto de integración

El almacén de datos carga y procesa información de muchos sistemas de origen. Y para mantener "relaciones amistosas" con ellos, debe tener mucho cuidado con ellos. En particular, es necesario minimizar la carga en los sistemas fuente, tener en cuenta las ventanas de "disponibilidad e indisponibilidad", seleccionar interfaces de interacción teniendo en cuenta su arquitectura, etc. Entonces, el almacenamiento podrá recoger datos lo antes posible y con la frecuencia requerida. De lo contrario, será "trasplantado" a un circuito de respaldo, que no se actualiza con la frecuencia más operativa.
Además, es necesario tener en cuenta el "factor humano". La integración no se trata solo de la interacción de máquinas. También es comunicación entre personas.

El almacén de datos es un proyecto colaborativo

En una gran empresa, un solo equipo rara vez puede realizar un sistema de este tipo. Por regla general, aquí trabajan varios equipos, cada uno de los cuales resuelve un problema específico.

La arquitectura debe proporcionar la capacidad de organizar su trabajo paralelo, manteniendo su integridad y evitando la duplicación de la misma funcionalidad en diferentes lugares, por diferentes personas. Además de un esfuerzo innecesario, dicha duplicación puede dar lugar a discrepancias de datos más adelante.

Además, cuando tantas personas y equipos, a menudo dispersos, están involucrados en el desarrollo del sistema, surge inevitablemente la pregunta: cómo construir comunicaciones e interacción de información entre ellos. Cuantos más enfoques y prácticas estándar y comprensibles se utilicen, más fácil, más conveniente y eficiente será organizar dicho trabajo. Y, entre otras cosas, vale la pena pensar en la composición de los "artefactos de trabajo", entre los que para los almacenes de datos # 1 se encuentran los modelos de datos (ver la sección anterior).

El almacén de datos tiene una vida útil más larga que otros sistemas.

Para aclarar: la afirmación es cierta para un almacenamiento de trabajo "en vivo", integrado con fuentes clave, que posee datos históricos y proporciona información y servicios analíticos a muchas divisiones de la empresa.

¿Qué motivos tengo para creerlo?
En primer lugar, la construcción de un almacenamiento es un proceso que requiere muchos recursos: además de los costos reales de los equipos, las licencias para el software tecnológico necesario y el desarrollo, casi todos los sistemas y divisiones de la empresa también están involucrados en esto. Repetir todo este proceso desde cero una vez más es una idea muy atrevida.

En segundo lugar, si el almacenamiento tiene la arquitectura correcta, puede sobrevivir fácilmente a los cambios de los sistemas de origen, a la aparición de nuevos requisitos de los usuarios finales y al crecimiento de los volúmenes de datos.
Si la arquitectura es correcta, los flujos de información son transparentes, entonces dicho sistema se puede desarrollar durante mucho tiempo sin el riesgo de quedar atrapado en una situación al realizar cambios debido a las dificultades para evaluar el impacto.

Desarrollo iterativo gradual

Lo último que le gustaría al Cliente, involucrarse en la historia con el repositorio, es congelar sus requisitos durante uno o dos años, hasta que se diseñe un modelo de datos corporativos completo, todas las fuentes estén completamente conectadas, etc.

A los ojos de los clientes, el almacén de datos a menudo parece un monstruo absoluto: las tareas, los objetivos y el horizonte de desarrollo del sistema son muy voluminosos. Y a menudo el cliente teme que "a expensas de su presupuesto" el departamento de TI resuelva algunos "sus problemas". Y nuevamente nos enfrentamos al tema de la interacción entre las personas y la capacidad de expresar con calma nuestra posición y negociar.

Los enfoques arquitectónicos competentes le permiten desarrollar el sistema de manera iterativa, aumentando la funcionalidad gradualmente, sin entrar en "desarrollo" durante varios años antes de comenzar a dar un resultado.

Aunque debe tenerse en cuenta que "los milagros no suceden", y el "comienzo" también lleva tiempo. En el caso de los almacenamientos, puede ser bastante grande, dado que se trata de grandes cantidades de datos, se trata de datos históricos, para los períodos anteriores, cuando las reglas para procesar la información podrían diferir de las actuales. Por lo tanto, se necesita suficiente tiempo para el trabajo analítico, la interacción con los sistemas de origen y una serie de "prueba y error", incluidas las pruebas de carga en datos reales.

Almacenes de datos: "historia de varios proyectos"

Es difícil seleccionar un solo cliente comercial para un almacén de datos. Y se cree (no sin razón) que el factor clave en el éxito del proyecto de construcción de una instalación de almacenamiento es el apoyo de la dirección de la empresa, directamente la primera persona.
Rara vez se crea y desarrolla un repositorio como parte de un solo proyecto. Por lo general, existen diferentes necesidades de consolidación y análisis de datos, detrás de ellas hay diferentes clientes y grupos de usuarios. Por lo tanto, el repositorio se desarrolla a menudo en el marco de varios proyectos paralelos.

Equilibrio de innovación y soluciones probadas

A pesar de que el tema del almacenamiento es muy "antiguo" (si tal palabra es aplicable a una industria tan joven como la informática) y bastante conservador. Sin embargo, el progreso no se detiene, y las limitaciones que existían anteriormente debido a discos costosos y lentos, memoria costosa, etc. - ahora se eliminan. Al mismo tiempo, ha llegado el momento de revisar algunos de los enfoques arquitectónicos. Además, esto se aplica tanto a las plataformas tecnológicas como a la arquitectura de los sistemas aplicados que se basan en ellas.

Es importante lograr un equilibrio aquí y mantener un enfoque bastante "verde" tanto para los recursos como para la información almacenada. De lo contrario, puede convertir rápidamente el almacenamiento en un "volcado" semiestructurado, en el que, si es posible resolverlo, con bastante esfuerzo.
Sí, tenemos más oportunidades, pero esto no significa que tengamos que negar todas las prácticas acumuladas y probadas por el tiempo, que está claro cómo y por qué usar, y "ir todo mal" solo de la mano del fantasma brumoso de " innovaciones ".
Mantener el equilibrio significa utilizar nuevos métodos y enfoques en los que se abren nuevas oportunidades, pero al mismo tiempo se utilizan antiguas y probadas, para resolver problemas urgentes que no han sido cancelados.
¿Qué podemos hacer como desarrolladores y diseñadores de soluciones de aplicaciones? En primer lugar, conocer y comprender los cambios tecnológicos de las plataformas en las que trabajamos, sus capacidades, características y límites de aplicación.

Miremos al DBMS como la plataforma tecnológica más crítica e importante para el almacenamiento.
Recientemente, ha habido una clara deriva de las bases de datos relacionales, creadas inicialmente como "universales", hacia la especialización. Durante mucho tiempo, los proveedores líderes han lanzado varias opciones para aplicaciones de diferentes clases (OLTP, DSS y DWH). Además, aparecen oportunidades adicionales para trabajar con texto, datos geográficos, etc.

Pero este no fue el final: comenzaron a aparecer productos que inicialmente se centraban en una determinada clase de tareas, es decir, DBMS especializado. Pueden usar o no el modelo relacional. Es importante que inicialmente estén "afinados" no solo para almacenar y procesar "información comercial" en general, sino también para tareas específicas.

Al parecer, la centralización y la especialización son dos tendencias complementarias que se reemplazan periódicamente, asegurando el desarrollo y el equilibrio. Así como el desarrollo evolutivo (gradual) gradual y los cambios cardinales. Por ejemplo, en los años 90, Michael Stonebreaker fue uno de los autores del Manifiesto de Bases de Datos de la Generación III, que expresaba claramente la idea de que el mundo no necesita otra revolución en el mundo de las bases de datos. Sin embargo, 10 años después, publica trabajos en los que anuncia los requisitos previos para el inicio de una nueva era en el mundo de los DBMS, en función de su especialización.
Se centra en el hecho de que los DBMS universales comunes se basan en una arquitectura de "talla única", que no tiene en cuenta ni los cambios en las plataformas de hardware ni la división de las aplicaciones en clases para las que se puede llegar a más solución óptima que la implementación de requisitos universales.
Y comienza a desarrollar una serie de proyectos de acuerdo con esta idea. Uno de ellos, C-Store, es un DBMS en columnas diseñado en la arquitectura de nada compartido (SN), creado originalmente específicamente para sistemas de la clase de almacenes de datos. A continuación, este producto se comercializó como HP Vertica.

Parece que ahora el tema del desarrollo de almacenes de datos se ha deslizado hacia una nueva etapa de desarrollo. Aparecen nuevas tecnologías, enfoques y herramientas. Su estudio, testeo y aplicación inteligente nos permite crear soluciones realmente interesantes y útiles. Y llévelos a la implementación, disfrutando del hecho de que sus desarrollos se utilizan en el trabajo real y son útiles.

Epílogo

Al preparar este artículo, traté de centrarme principalmente en arquitectos, analistas y desarrolladores que trabajan directamente con almacenes de datos. Pero resultó que inevitablemente "amplió un poco el tema", y otras categorías de lectores entraron en el campo de visión. Algunos puntos parecerán controvertidos, algunos no están claros, algunos son obvios. Las personas son diferentes, con diferentes antecedentes, antecedentes y posiciones.
Por ejemplo, las preguntas gerenciales típicas son "¿cuándo contratar arquitectos?", "¿Cuándo tratar con la arquitectura?" Para nosotros (desarrolladores, diseñadores) suena bastante extraño, porque para nosotros la arquitectura del sistema aparece con su nacimiento, no importa si somos conscientes de ello o no. E incluso si no hay un papel formal de un arquitecto en un proyecto, un desarrollador normal siempre "incluye su propio arquitecto interno".

En general, no importa quién desempeña exactamente el papel del arquitecto; es importante que alguien haga preguntas similares e investigue las respuestas. Si se destaca claramente al arquitecto, esto solo significa que es el principal responsable del sistema y su desarrollo.
¿Por qué encontré el tema de la "antifragilidad" relevante para este tema?

"La singularidad de la antifragilidad es que nos permite trabajar con lo desconocido, hacer algo en condiciones en las que no entendemos qué es exactamente lo que estamos haciendo y lograr el éxito"./ Nassim N. Talb /

Por tanto, la crisis y un alto grado de incertidumbre no son una excusa a favor de la ausencia de arquitectura, sino factores que refuerzan su necesidad.

Epílogo

"La singularidad de la antifragilidad es que nos permite trabajar con lo desconocido, hacer algo en condiciones en las que no entendemos qué es exactamente lo que estamos haciendo y lograr el éxito"./ Nassim N. Talb /

Por tanto, la crisis y un alto grado de incertidumbre no son una excusa a favor de la ausencia de arquitectura, sino factores que refuerzan su necesidad.

Etiquetas: Agregar etiquetas

5.1. Organización de datos en sistemas de información corporativos.

Considerando el CIS en el nivel más simplificado, podemos decir que contiene una red informática corporativa (informática) y un paquete de aplicaciones especializadas (PPP) para resolver problemas en el área temática. A su vez, tanto el PPP como la red informática presuponen el uso de datos de información sobre el estado y desarrollo de los sistemas controlados y controlados por ellos. Históricamente, el CIS consta de subsistemas separados y ramificados de empresas individuales, interconectados y que a menudo representan un sistema jerárquico. Es natural suponer que tales subsistemas tienen sus propias fuentes y sus propias ubicaciones de almacenamiento para datos relacionados. Combinando en un solo sistema, surgen preguntas sobre el uso correcto conjunto de datos ubicados geográficamente en diferentes lugares de su almacenamiento. En consecuencia, para la gestión exitosa de una asociación de producción equipada con un ICC, se necesita un sistema confiable para recopilar, almacenar y procesar datos. En otras palabras, necesita una infraestructura de información unificada que cumpla con los proyectos estratégicos de BI (Business Intelligence) o una base de datos integrada para almacenar y usar datos. El objetivo principal de la integración de datos es obtener una imagen unificada y coherente del estado de los datos comerciales corporativos. La integración en sí es un proceso complejo, a partir del cual conviene destacar:

Tecnologías,

Productos

Aplicaciones.

Métodos Son enfoques para la integración de datos.

Tecnologias- estos son procesos que implementan ciertos métodos de integración de datos.

Productos Son soluciones comerciales que soportan una u otra tecnología de integración de datos.

Aplicaciones- estas son soluciones técnicas listas para usar suministradas por desarrolladores de acuerdo con los deseos de los clientes - clientes.

Dependiendo de la complejidad de los sistemas de información corporativos y de las tareas para las que están diseñados, la organización de los datos en ellos es algo diferente. En particular, en el CIS, diseñado para garantizar una gestión eficaz de los procesos comerciales tanto de las sucursales individuales como de la corporación en su conjunto, se acostumbra hablar de la presencia de bases de datos corporativas. En los sistemas de información corporativos utilizados en los más altos niveles de gestión y mayoritariamente asociados a los procesos de análisis operativo y toma de decisiones, en el proceso de planificación, diseño y previsión de diversos tipos de actividades de gestión, utilizan la terminología de un data warehouse. Es pertinente señalar que la frase almacenamiento integrado inherente a ambos.

5.2. Bases de datos corporativas y requisitos para ellas

Como almacenamiento de datos integrado en todo el sistema, la base de datos corporativa está diseñada para proporcionar información para la gestión eficaz de todos los procesos comerciales y divisiones de la corporación. La integración de datos proporciona la creación de una nueva estructura que incluye orgánicamente datos de las bases de datos de divisiones separadas separadas, por lo tanto, dicha estructura debe proporcionar ciertos requisitos:

Entrada de datos simple y fácil de usar en la base de datos,

Almacenar datos de una manera que no conduzca a un crecimiento excesivo de datos,

Accesibilidad a la información general de los empleados de todas las divisiones de la corporación, con la condición obligatoria de diferenciación de derechos de acceso,

Encontrar y recuperar rápidamente la información requerida,

Ordenar y filtrar los datos requeridos,

Agrupación de datos del mismo nombre,

Cálculos intermedios y finales sobre los campos,

· Conversión y claridad de los datos de salida,

Escalabilidad

· Protección contra fallas accidentales, pérdida irrecuperable de datos y acceso no autorizado.

Además, al integrar bases de datos aisladas (distribuidas) en una única base de datos corporativa, es importante garantizar la capacidad de trabajar con la base de datos de tal manera que el usuario trabaje con ella como con una no asignada.

La creación de una base de datos corporativa integrada es posible mediante varios métodos, los principales de los cuales son:

Consolidación,

Federalización,

· Difusión.

5.3. Características de las soluciones de integración de bases de datos corporativas

Consolidación. Debajo consolidación generalmente significa la adición de datos del mismo nombre. Un término similar es muy utilizado en el sector bancario, donde se forma un balance anual consolidado, que permite presentar todos los activos y pasivos del banco matriz junto con sus sucursales.

Según se aplica a una corporación, cuando se utiliza este método, los datos se copian y recopilan de las bases de datos primarias (DB - Slave) mediante la integración en una única ubicación de almacenamiento (DB - Master). Como regla general, el servidor de la oficina central (central) se elige como tal ubicación de almacenamiento (Figura 5.1).

Figura 5.1. Método de consolidación de datos

Datos en la base de datos - Master se utiliza para informes, análisis, desarrollo y toma de decisiones, así como también como fuente de datos para otras ramas de la corporación.

Las tecnologías más comunes para respaldar tales decisiones durante la consolidación son las siguientes tecnologías:

· Extracción, transformación y carga - ETL (Extract Transform Load);

· Gestión del contenido de la corporación - ECM (Enterprise Content Management).

Las ventajas del método de consolidación son:

1. Capacidad para realizar transformaciones(reestructuración, conciliación, limpieza y / o agregación) de cantidades significativas de datos en el proceso de su transferencia desde los sistemas primarios a las ubicaciones finales de almacenamiento utilizando tecnología ETL,

2. Capacidad para administrar datos no estructurados como documentos, informes y páginas gracias a las soluciones de tecnología ECM.

Para trabajar con la base de datos CIS consolidada, especial aplicaciones de negocios, que le permiten crear consultas a datos de bases de datos, informes y, en base a ellos, realizar análisis de datos.

La desventaja de la integración a través de la consolidación es la imposibilidad de actualizar los datos consolidados en la ubicación de almacenamiento integrado en sincronía con las actualizaciones de datos en los sistemas primarios debido a los conflictos que surgen durante la sincronización.

Existe un lapso de tiempo entre la actualización de los datos en los sistemas primarios y la ubicación de almacenamiento final.

Este retraso puede variar desde unos pocos segundos hasta varias horas o incluso días.

Federalización. Debajo federalización generalmente significa unión. Un término similar se usa a menudo en política al organizar las fronteras estatales (por ejemplo, Alemania, Rusia, EE. UU.).

El proceso de federalización de datos en una base de datos corporativa es la creación de una imagen virtual (aparente) que combina varios archivos de datos primarios en un solo todo virtual (ver Figura 5.2). La federación de datos en sí se trata de extraer datos de sistemas primarios en función de requisitos externos. La gestión del trabajo de la base de datos corporativa integrada según el método federal es realizada por procesador de federalización.

Figura 2. Método de federación de datos

Al acceder a los datos en una base de datos virtual, cualquier aplicación empresarial genera una solicitud a la imagen virtual. El procesador de la federación, basándose en esta solicitud, extrae datos de los respectivos sistemas primarios, los integra de acuerdo con la imagen virtual y envía el resultado a la aplicación comercial que generó la solicitud. En este caso, todas las transformaciones de datos necesarias se llevan a cabo cuando se extraen de los sistemas primarios.

El soporte de un enfoque federado para la integración de datos lo proporciona la tecnología de integración de información empresarial (E I I), que en traducción significa: la integración de información corporativa.

Una característica de la solución federada es que el procesador de federalización usa metadatos(conocimiento), que incluyen datos sobre la composición y características de la imagen virtual, sobre la cantidad de datos, las relaciones semánticas entre ellos y las formas de acceder a ellos, ayudando a la solución federada a optimizar el acceso a los sistemas primarios.

Las principales ventajas del enfoque federado son:

La capacidad de acceder a los datos actuales sin crear una nueva base de datos adicional,

Conveniencia de la aplicación después de la adquisición o fusión de empresas,

Irreemplazable en casos donde, por razones de seguridad, existen restricciones de licencia para copiar datos de sistemas primarios,

Utilizar, si es necesario, la alta autonomía de las divisiones locales de la corporación y la flexibilidad del control centralizado de sus actividades,

· Alto grado de utilidad para las grandes corporaciones transnacionales.

Las desventajas de este enfoque incluyen:

Disminución del rendimiento debido al costo adicional de acceder a múltiples fuentes de datos,

La federalización es más apropiada para recuperar pequeñas cantidades de datos,

· Elevados requisitos para la calidad de los datos primarios.

Extensión. Debajo diseminación generalmente se refiere a la transferencia territorial de objetos multiplicados. La difusión de datos se refiere a la propagación de bases de datos primarias y su movimiento de un lugar a otro. Al implementar este método aplicaciones de negocios operan en línea y mueven datos a destinos en función de eventos específicos que ocurren. Para esta solución técnica, la cuestión de las actualizaciones de datos, que son posibles en los modos síncrono o asíncrono, se vuelve importante. El modo síncrono asume que las actualizaciones tanto del sistema primario como del sistema de destino ocurren durante la misma transacción física.

Ejemplos de tecnologías que apoyan la implementación de un método de difusión de datos son:

Integración de aplicaciones empresariales EAI - Integración de aplicaciones empresariales,

· Replicación de datos corporativos EDR - Enterprise Data Replication.

La estructura generalizada de la implementación del método de difusión de datos se muestra en la Figura 5.3.

Figura 5.3. Método de difusión de datos

Una característica distintiva del método de distribución de datos es la entrega garantizada de datos al sistema de destino con un retraso mínimo cercano al tiempo real.

La combinación de tecnologías de integración (EAI) y replicación (EDR) proporciona múltiples ventajas, en forma de las siguientes ventajas:

· Alto rendimiento,

· Capacidad para reestructurar y limpiar datos,

· Equilibrar la carga mediante la creación de copias de seguridad y la restauración de datos.

Enfoque híbrido. Las realidades de la actividad económica son tales que no hay dos empresas idénticas, y mucho menos dos corporaciones idénticas. Esta circunstancia deja huella en el proceso de creación y llenado del sistema de información corporativo. Esto también se aplica por completo a los métodos de integración de datos en bases de datos. Por esta razón, muchos sistemas CIS utilizan los llamados híbrido un enfoque que involucra múltiples métodos de integración al mismo tiempo, ejemplos de los cuales son tecnologías que brindan una imagen consistente de la información del cliente:

Integración de datos de clientes en sistemas CDI - Integración de datos de clientes,

· Integración de datos de clientes en módulos CRM - Customer Relations Management.

En particular, un enfoque de implementación de CDI se puede lograr de diversas formas.

La forma más sencilla es crear una base de datos de clientes consolidada que contenga datos de los sistemas primarios. Al mismo tiempo, el rezago de la información se puede regular mediante el uso de varios modos de consolidación: operativo o por lotes, según la frecuencia de actualización de esta información.

La segunda forma es la federación de datos, cuando es virtual Presentación de negocios datos del cliente contenidos en sistemas primarios. Y el archivo de metadatos puede contener elementos clave generales que se pueden utilizar para relacionar la información del cliente.

Por lo tanto, los datos generales de los clientes (por ejemplo, los detalles) se pueden consolidar como los datos más estáticos. Y los datos más dinámicos (como la información de pedidos) se pueden federalizar.

Además, el enfoque híbrido puede ampliarse utilizando el método de difusión de datos. Por ejemplo, un cliente que utiliza los servicios de una tienda de Internet, durante el servicio, cambia sus datos. Estos cambios pueden enviarse a la parte consolidada de la base de datos y, desde allí, propagarse a todos los sistemas primarios que contienen datos sobre los clientes de la tienda.

Teniendo en cuenta las ventajas y desventajas de cada uno de los métodos, es recomendable abordar de forma creativa su aplicación y uso conjunto.

Por ejemplo, la federación de datos es útil cuando los costos de consolidación de datos superan los beneficios comerciales que brinda la consolidación. En particular, el procesamiento en línea de solicitudes y la preparación de informes es exactamente esa situación.

Las aplicaciones prácticas del método de difusión de datos son muy diversas, tanto en términos de rendimiento como en términos de capacidad para reestructurar y depurar datos.

5.4. El concepto y las soluciones estructurales de los almacenes de datos.

Almacén de datos - es un almacenamiento integrado de información orientado al sujeto que acumula datos externos y operativos, así como datos de otros sistemas, sobre cuya base se construyen los procesos de toma de decisiones y análisis de datos.

A diferencia de las bases de datos y los bancos de datos, la base de los almacenes de datos no son fuentes de datos internas, sino externas: diversos sistemas de información, archivos electrónicos, catálogos electrónicos públicos, libros de referencia y colecciones.

El concepto de almacén de datos se basa en dos ideas principales:

1. Integración de datos detallados desagregados (que describen hechos específicos, propiedades, eventos, etc.) en un solo repositorio.

2. Separación de conjuntos de datos y aplicaciones utilizadas para procesamiento y análisis.

El data warehouse se organiza en los casos en los que es necesario obtener:

Integración de valores de datos actuales e históricos,

Combinando datos de fuentes dispares,

Creación de una plataforma de datos confiable con fines analíticos,

Garantizar la coherencia de los datos en toda la organización.

Facilitar la implementación de estándares de datos corporativos sin cambiar los sistemas operativos existentes,

· Proporcionar un panorama histórico amplio y oportunidades para analizar las tendencias de desarrollo.

Históricamente, los almacenes de datos se han construido en un esquema de uno, dos y tres niveles.

Esquemas de un solo nivel fueron originalmente pensados para las arquitecturas más simples, que incluyen DSS funcionales, con una infraestructura de información insuficientemente desarrollada, cuando el análisis se realiza utilizando datos de sistemas operativos, de acuerdo con el principio: datos - formas de presentación.

Las ventajas de tales esquemas son:

Transferencia rápida de datos desde sistemas operativos a un sistema especializado sin enlaces intermedios,

· Costes mínimos por el uso de una única plataforma.

Desventajas:

Una gama limitada de problemas que deben resolverse debido a una única fuente de datos,

· Mala calidad de los datos debido a la falta de un paso de limpieza.

Esquemas de dos niveles proporcionar una cadena: datos - mercados de datos - formularios de presentación. Se utilizan en empresas con un gran número de divisiones independientes que utilizan sus propias tecnologías de la información.

Ventajas:

Las vitrinas utilizadas están diseñadas para responder a un conjunto específico de preguntas,

· Es posible optimizar los datos en los data marts para mejorar el rendimiento.

Desventajas:

Dificultad para garantizar la coherencia de los datos debido a su repetición múltiple en escaparates,

Potencial complejidad de los mercados de datos que se llenan con una gran cantidad de fuentes de datos,

· Debido a la falta de consolidación de datos a nivel corporativo, no existe una imagen única del negocio.

La evolución del desarrollo ha llevado al hecho de que la construcción de un almacén de datos completo para sistemas corporativos modernos comenzó a ser realizada por arquitectura de tres niveles (ver Figura 5.4).

Sobre primero el nivel contiene una variedad de sistemas de registro que son fuentes de datos. Dichos sistemas pueden ser sistemas de planificación de recursos empresariales (ERP - Enterprise Resource Planning), sistemas de referencia (operativos), fuentes externas o sistemas que suministran datos de agencias de información, etc.

Sobre segundo El nivel contiene un almacenamiento central, donde se recopilan datos de todas las fuentes del primer nivel, así como un almacén de datos operativos, que está diseñado para realizar dos funciones:

El almacén es una fuente de información analítica utilizada para la gestión operativa,

· En el almacén operativo, los datos se preparan para su posterior carga en el almacén central. La preparación de datos significa la realización de verificaciones y transformación de datos en relación con diversas normativas para la recepción de datos del primer nivel.

Tercera un nivel es una colección de mercados de datos de dominios específicos.

Data marts - estos son impulsos relativamente pequeños orientados funcionalmente, cuyo contenido contribuye a la solución de tareas analíticas de divisiones individuales de la corporación. De hecho, los data marts son subconjuntos de datos de un almacén. Al mismo tiempo, los usuarios finales tienen la capacidad de acceder a datos detallados del almacén, en caso de que no haya suficientes datos en el mercado, así como para obtener una imagen más completa del estado del negocio.

Figura 5.4. Arquitectura de almacenamiento de datos

Las principales operaciones tecnológicas de tales almacenes de datos organizados son:

· Recuperando datos es el proceso de transferir datos de fuentes heterogéneas a un almacén operativo,

· Transformación los datos son una modificación de datos basada en reglas especiales con su posterior transferencia a un almacenamiento central,

· Limpieza datos es la eliminación de la duplicación de datos provenientes de diferentes fuentes,

· Actualizar Los datos son la propagación de una actualización de datos a los datos originales de las tablas base y los datos derivados alojados en el almacén.

Ventajas:

· El llenado de escaparates se simplifica debido al uso de una única fuente de datos depurados,

Los data marts están sincronizados con la imagen empresarial corporativa, lo que facilita la expansión del repositorio central y la adición de data marts.

· Rendimiento garantizado.

Desventajas:

La presencia de redundancia de datos, lo que lleva a un aumento de los requisitos para la tecnología de almacenamiento de datos.

5. 5. Sistemas y tecnologías de gestión de bases de datos para acceder a datos en CIS

Sistema de administración de base de datos(DBMS) es un conjunto de herramientas de software y lenguaje diseñado para crear, mantener y compartir una base de datos por uno o varios usuarios.

Actualmente, los más extendidos son los DBMS construidos sobre la base de un modelo de datos relacionales descrito por un riguroso aparato matemático teoría de las relaciones.

Una característica de los DBMS que funcionan en el sistema de información corporativo es el hecho de que deben administrar bases de datos ubicadas en medios distribuidos en el espacio.

Con el fin de eliminar la duplicación o copia adicional de datos en el CIS, el énfasis principal está en el principio del procesamiento de datos a distancia. Las bases de datos en CIS contienen datos requeridos por muchos usuarios. Es posible obtener acceso simultáneo de varios usuarios a la base de datos al instalar en una red informática local DBMS que trabajen con usuarios y con una sola base de datos.

Las principales soluciones tecnológicas para el trabajo multiusuario con bases de datos son las tecnologías archivo / servidor y cliente / servidor. Tomando la opción más adecuada de estas tecnologías, el cliente / servidor en el CIS son sistemas organizados especializados para procesar bases de datos distribuidas. En este caso, la gestión de las bases de datos distribuidas se realiza de tal forma que los datos se distribuyen no a nivel lógico, sino a nivel físico, y la base de datos en sí se considera como un único "supercircuito". En una base de datos distribuida, las funciones administrativas se distribuyen entre el administrador de la base de datos integrada y los administradores de la base de datos local. El administrador de base de datos integrado monitorea la diferenciación de acceso de diferentes usuarios a la base de datos y asegura la integridad y seguridad de los datos, así como la protección de los datos de su corrección simultánea por varios usuarios. El control de acceso se lleva a cabo de acuerdo con los derechos otorgados a los usuarios individuales en el sistema operativo de la red.

Un rasgo característico de los programas creados usando el DBMS para trabajar con bases de datos corporativas remotas y distribuidas es el uso de una interfaz de acceso a datos abierta - ODBC (Open Data Base Connectivity). Todas las funciones para la transferencia de datos se asignan a la interfaz ODBC, que es un puente de conexión entre la base de datos integrada DBMS y la aplicación cliente DBMS. En este caso, el DBMS del cliente puede interactuar no solo con sus bases de datos locales, sino también con los datos ubicados en la base de datos integrada. El cliente tiene la capacidad de enviar solicitudes a la base de datos integrada DBMS, recibir datos sobre ellos y enviar sus propios datos actualizados.

Modelos de datos de la industria

El propósito principal de los modelos es facilitar la orientación en el espacio de datos y ayudar a resaltar los detalles que son importantes para el desarrollo empresarial. En el entorno actual, para un negocio exitoso, es imperativo tener una comprensión clara de los vínculos entre los diversos componentes y tener una buena idea del panorama general de la organización. La identificación de todos los detalles y relaciones mediante modelos permite el uso más eficiente del tiempo y las herramientas para organizar el trabajo de la empresa.

Los modelos de datos son modelos abstractos que describen cómo se presentan y se accede a los datos. Los modelos de datos definen elementos de datos y las relaciones entre ellos en un área en particular. Un modelo de datos es una herramienta de navegación para profesionales de TI y negocios que utiliza un conjunto específico de símbolos y palabras para explicar con precisión una clase específica de información del mundo real. Esto permite una mejor comunicación dentro de la organización y, por lo tanto, crea un entorno de aplicación más flexible y estable.

El modelo de datos define de forma única el significado de los datos, que en este caso son datos estructurados (a diferencia de los datos no estructurados como, por ejemplo, una imagen, un archivo binario o un texto, donde el significado puede ser ambiguo).

Como regla general, se distinguen modelos de un nivel superior (y más general en contenido) y uno inferior (respectivamente, más detallado). El nivel superior de modelado es el llamado modelos de datos conceptuales(modelos de datos conceptuales), que ofrecen la imagen más general del funcionamiento de una empresa u organización. El modelo conceptual incluye los principales conceptos o áreas temáticas que son críticas para el funcionamiento de la organización; por lo general, su número no supera los 12-15. Dicho modelo describe las clases de entidades que son importantes para la organización (objetos comerciales), sus características (atributos) y las asociaciones entre pares de estas clases (es decir, relaciones). Dado que la terminología en el modelado de negocios aún no se ha establecido finalmente, en varias fuentes en inglés, los modelos de datos conceptuales también pueden denominarse modelo de área temática (que se puede traducir como modelos de dominio) o modelo de datos empresariales temáticos (datos corporativos temáticos). modelos).

El siguiente nivel jerárquico es modelos de datos lógicos(modelos de datos lógicos). También pueden denominarse modelos de datos empresariales o modelos de negocio. Estos modelos contienen estructuras de datos, sus atributos y reglas comerciales, y representan la información utilizada por una empresa desde una perspectiva comercial. En tal modelo, los datos se organizan en forma de entidades y relaciones entre ellas. El modelo lógico presenta los datos de una manera que facilita la comprensión de los usuarios comerciales. En un modelo lógico, se puede distinguir un diccionario de datos: una lista de todas las entidades con sus definiciones precisas, que permite que las diferentes categorías de usuarios tengan una comprensión común de todos los flujos de entrada y salida de información del modelo. El siguiente nivel más bajo de modelado es la implementación física del modelo lógico utilizando software y plataformas técnicas específicas.

El modelo lógico contiene una decisión empresarial corporativa detallada, que generalmente toma la forma de un modelo normalizado. La normalización es un proceso que garantiza que cada elemento de datos en un modelo tenga un solo valor y sea total y exclusivamente dependiente de la clave principal. Los elementos de datos se organizan en grupos de acuerdo con su identificación única. Las reglas comerciales que rigen los elementos de datos deben incorporarse completamente en el modelo normalizado con validación y validación previas. Por ejemplo, es probable que un elemento de datos como el Nombre del cliente se divida en Nombre y Apellido y se agrupe con otros elementos de datos relacionados en una entidad Cliente con una ID de cliente de clave principal.

El modelo de datos lógicos es independiente de las tecnologías de aplicación, como bases de datos, tecnologías de redes o herramientas de informes, y los medios de su implementación física. Solo puede haber un modelo de datos empresarial en una organización. Los modelos lógicos suelen incluir miles de entidades, relaciones y atributos. Por ejemplo, un modelo de datos para una institución financiera o una empresa de telecomunicaciones puede contener alrededor de 3000 conceptos de la industria.

Es importante distinguir entre modelo de datos lógico y semántico. El modelo de datos lógicos representa una solución empresarial empresarial y el modelo de datos semánticos representa una solución empresarial aplicada. El mismo modelo de datos lógicos corporativos se puede implementar utilizando diferentes modelos semánticos, es decir Los modelos semánticos pueden verse como el siguiente nivel de modelado que se acerca a los modelos físicos. Además, cada uno de estos modelos representará una "porción" separada del modelo de datos corporativos de acuerdo con los requisitos de diversas aplicaciones. Por ejemplo, en el modelo de datos lógicos corporativos, la entidad Cliente estará completamente normalizada y en el modelo semántico para el data mart, se puede representar como una estructura multidimensional.

Una empresa puede tener dos formas de crear un modelo de datos lógicos corporativos: construirlo de forma independiente o usar uno ya hecho. modelo de industria(modelo de datos lógicos de la industria). En este caso, las diferencias en términos reflejan solo enfoques diferentes para construir el mismo modelo lógico. En el caso de que una empresa desarrolle e implemente de forma independiente su propio modelo de datos lógicos, dicho modelo, por regla general, se denomina simplemente modelo lógico corporativo. Si una organización decide utilizar un producto listo para usar de un proveedor profesional, entonces podemos hablar de un modelo de datos lógicos de la industria. Este último es un modelo de datos lógicos listo para usar que refleja el funcionamiento de una industria en particular con un alto grado de precisión. Un modelo lógico de la industria es una vista integrada y específica del dominio de toda la información que debe residir en un almacén de datos empresarial para responder preguntas comerciales estratégicas y tácticas. Como cualquier modelo de datos lógicos, el modelo de industria es independiente de las decisiones de aplicación. Tampoco incluye datos derivados u otros cálculos para una recuperación de datos más rápida. Como regla general, la mayoría de las estructuras lógicas de tal modelo están bien incorporadas en su implementación física efectiva. Dichos modelos son desarrollados por muchos proveedores para una amplia variedad de áreas de actividad: finanzas, manufactura, turismo, salud, seguros, etc.

Un modelo de datos lógicos de la industria contiene información que es común a la industria y, por lo tanto, no puede ser una solución integral para una empresa. La mayoría de las empresas tienen que hacer crecer el modelo en un promedio del 25% agregando elementos de datos y expandiendo las definiciones. Los modelos listos para usar contienen solo elementos de datos clave, y el resto de los elementos deben agregarse a los objetos comerciales correspondientes durante la instalación del modelo en la empresa.

Los modelos de datos lógicos de la industria contienen una cantidad significativa de abstracción. Las abstracciones significan la unión de conceptos similares bajo nombres comunes como Evento o Participante. Esto agrega flexibilidad y uniformidad a los modelos de la industria. Por tanto, el concepto de Evento es aplicable a todas las industrias.

El especialista en inteligencia empresarial Steve Hoberman identifica cinco factores a considerar al decidir si adquirir un modelo de datos de la industria. El primero es el tiempo y el dinero necesarios para construir el modelo. Si una organización necesita lograr resultados rápidamente, entonces el modelo de industria será beneficioso. Es posible que el uso de un modelo de industria no proporcione de inmediato una imagen de toda la organización, pero puede ahorrar una cantidad significativa de tiempo. En lugar de modelar en sí mismo, se dedicará tiempo a vincular las estructuras existentes con el modelo de la industria y discutir la mejor manera de personalizarlo según las necesidades de la organización (por ejemplo, qué definiciones deben cambiarse y qué elementos de datos deben agregarse).

El segundo factor es el tiempo y el dinero necesarios para mantener el modelo en buen estado de funcionamiento. Si el modelo de datos empresariales no es parte de una metodología que le permite monitorear el cumplimiento de su precisión y el cumplimiento de los estándares modernos, entonces dicho modelo se vuelve obsoleto muy rápidamente. El modelo de datos de la industria puede evitar que suceda este riesgo, ya que se mantiene actualizado con recursos externos. Por supuesto, los cambios que tienen lugar dentro de la organización deben reflejarse en el modelo por parte de la propia empresa, pero los cambios de la industria serán reproducidos en el modelo por su proveedor.

El tercer factor es la experiencia en evaluación y modelización de riesgos. La creación de un modelo de datos corporativos requiere recursos calificados tanto de la empresa como del personal de TI. Como regla general, los gerentes conocen bien el trabajo de la organización en su conjunto o las actividades de un departamento en particular. Pocos tienen un conocimiento amplio (de toda la empresa) y profundo (dentro de los departamentos) de su negocio. La mayoría de los gerentes generalmente conocen bien solo un área. Por lo tanto, para obtener una imagen corporativa general, se requieren importantes recursos comerciales. Esto también aumenta las demandas del personal de TI. Cuantos más recursos comerciales se requieran para crear y probar un modelo, más experimentados deben ser los analistas. No solo deben saber cómo obtener información del personal de la empresa, sino también poder encontrar un punto de vista común en áreas contenciosas y poder presentar toda esta información de manera integrada. La persona que crea el modelo (en muchos casos el mismo analista) debe tener buenas habilidades de modelado. La construcción de modelos lógicos empresariales requiere modelar "para el futuro" y la capacidad de convertir literalmente negocios complejos "en cuadrados y líneas".

Por otro lado, el modelo de la industria permite aprovechar la experiencia externa. Los modelos lógicos específicos de la industria se crean utilizando metodologías de modelado probadas y equipos de profesionales experimentados para evitar problemas comunes y costosos que pueden surgir al desarrollar modelos de datos empresariales dentro de una organización.

El cuarto factor es la infraestructura de aplicaciones existente y las relaciones con los proveedores. Si una organización ya utiliza muchas herramientas del mismo proveedor y ha establecido relaciones con él, entonces tiene sentido y el modelo de la industria se encarga de él. Este modelo podrá trabajar libremente con otros productos del mismo proveedor.

El quinto factor es el intercambio de información dentro de la industria. Si una empresa necesita comunicarse con otras organizaciones que trabajan en el mismo campo, entonces el modelo de industria puede ser muy útil en esta situación. Las organizaciones dentro de la misma industria utilizan componentes estructurales y terminología similares. Hoy en día, en la mayoría de las industrias, las empresas se ven obligadas a intercambiar datos para realizar negocios con éxito.

Los más efectivos son los modelos de industria ofrecidos por proveedores profesionales. Se logra una alta eficiencia de su uso debido al significativo nivel de detalle y precisión de estos modelos. Por lo general, contienen muchos atributos de datos. Además, los creadores de estos modelos no solo tienen una amplia experiencia en modelado, sino que también están bien versados en la construcción de modelos para una industria en particular.

Los modelos de datos de la industria brindan a las empresas una vista única e integrada de su información comercial. A muchas empresas les resulta difícil integrar sus datos, aunque este es un requisito previo para la mayoría de los proyectos empresariales. Según un estudio realizado por The Data Warehousing Institute (TDWI), más del 69% de las organizaciones encuestadas encontraron que la integración es una barrera importante para la adopción de nuevas aplicaciones. Por el contrario, la implementación de la integración de datos genera ingresos tangibles para la empresa.

El modelo de datos de la industria, además de vincularse a los sistemas existentes, proporciona grandes beneficios para proyectos de toda la empresa, como la planificación de recursos empresariales (ERP), la gestión de datos maestros, la inteligencia empresarial, la mejora de la calidad de los datos y el desarrollo de los empleados.

Por lo tanto, los modelos de datos lógicos de la industria son una herramienta eficaz para integrar datos y obtener una visión holística del negocio. El uso de modelos lógicos parece ser un paso necesario hacia la creación de almacenes de datos corporativos.

Publicaciones

Steve Hoberman. Aprovechando el modelo de datos lógicos de la industria como su modelo de datos empresarial.
Claudia Imhoff. Proyectos de inteligencia empresarial y almacenamiento de datos de seguimiento rápido mediante el modelado inteligente de datos

La base de datos corporativa es el enlace central del sistema de información corporativa y le permite crear un espacio de información único para la corporación. Bases de datos corporativas

Comparte tu trabajo en las redes sociales

Si este trabajo no le conviene en la parte inferior de la página, hay una lista de trabajos similares. También puede utilizar el botón de búsqueda

TEMA V. BASES DE DATOS CORPORATIVAS

V .1. Organización de datos en sistemas corporativos. Bases de datos corporativas.

V .2. DBMS y soluciones estructurales en sistemas corporativos.

V .3. Tecnologías de Internet / Intranet y soluciones corporativas para el acceso a bases de datos.

V .1. ORGANIZACIÓN DE DATOS EN SISTEMAS CORPORATIVOS. BASES DE DATOS CORPORATIVAS

Base corporativa Los datos son el enlace central del sistema de información corporativo y le permite crear un espacio de información único para la corporación. Bases de datos corporativas (Figura 1.1).

Existen varias definiciones de bases de datos.

Bajo la base de datos (DB) comprender un conjunto de información conectado lógicamente de tal manera que constituya un único conjunto de datos almacenados en los dispositivos de memoria de una computadora. Este conjunto actúa como el dato inicial de las tareas resueltas en el proceso de funcionamiento de los sistemas de control automatizados, los sistemas de procesamiento de datos, los sistemas informáticos y de información.

El término base de datos se puede resumir como una colección de datos relacionados lógicamente destinados a ser compartidos.

Bajo la base de datos Se entiende como un conjunto de datos que se almacenan conjuntamente con una redundancia mínima tal que les permite ser utilizados de forma óptima para una o más aplicaciones.

El propósito de crear bases de datos como formas de almacenamiento de datos construcción de un sistema de datos que no dependa de los algoritmos adoptados (software), los medios técnicos utilizados, la ubicación física de los datos en la computadora. La base de datos asume un uso polivalente (varios usuarios, muchas formas de documentos y solicitudes de un usuario).

Requisitos básicos para bases de datos:

Completitud de la presentación de datos. Los datos de la base de datos deben representar adecuadamente toda la información sobre el objeto y deben ser suficientes para SAO.
Integridad de la base de datos. Los datos deben ser guardados al momento de procesar sus ODS y en cualquier situación que surja durante el trabajo.
Flexibilidad de la estructura de datos. La base de datos debe permitir cambiar las estructuras de datos sin violar su integridad y exhaustividad cuando cambian las condiciones externas.
Factibilidad. Esto significa que debe haber una representación objetiva de varios objetos, sus propiedades y relaciones.
Disponibilidad. Es necesario proporcionar delimitación del acceso a los datos.
Redundancia. La base de datos debe tener una redundancia mínima en la representación de datos sobre cualquier objeto.

Conocimiento significa un conjunto de hechos, patrones y reglas heurísticas que se pueden usar para resolver el problema.

Base de conocimientos (KB)  un conjunto de bases de datos y reglas utilizadas obtenidas de los responsables de la toma de decisiones. La base de conocimientos es un elemento de los sistemas expertos.

Distinguir diferentes formas de presentar los datos.

Datos físicos - son datos almacenados en la memoria de la computadora.

Representación lógica de datos corresponde a una vista personalizada de datos físicos. La diferencia entre las representaciones físicas y lógicas correspondientes de los datos es que esta última refleja algunas relaciones importantes entre los datos físicos.

Bajo la base de datos corporativa Comprender una base de datos que reúna de una forma u otra todos los datos y conocimientos necesarios sobre la organización que se está automatizando. En los sistemas de información corporativos, un concepto comobases de datos integradas, en el que se implementa el principio de entrada única y uso repetido de la información.

Arroz. 1.1. La estructura de la interacción de los departamentos con los recursos de información de la corporación.

Las bases de datos corporativas son enfocado (centralizado) y distribuido.

Base de datos agrupada (centralizada) es una base de datos, cuyos datos se almacenan físicamente en los dispositivos de almacenamiento de una computadora. En la Fig. 1.2 presenta un diagrama de una aplicación de servidor para acceder a bases de datos en varias plataformas.

Figura 1.2. Esquema heterogéneo base de datos centralizada

La centralización del procesamiento de la información hizo posible eliminar las desventajas de los sistemas de archivos tradicionales como la incoherencia, la inconsistencia y la redundancia de datos. Sin embargo, a medida que las bases de datos crecen, y especialmente cuando se utilizan en organizaciones geográficamente dispersas, surgen problemas. Por ejemplo, para bases de datos concentradas ubicadas en el nodo de una red de telecomunicaciones, con la ayuda de las cuales varios departamentos de la organización obtienen acceso a los datos, con el crecimiento del volumen de información y el número de transacciones, surgen las siguientes dificultades:

Gran flujo de intercambio de datos;
Alto tráfico en la red;
Baja confiabilidad;
Rendimiento general deficiente.

Si bien es más fácil garantizar la seguridad, la integridad y la coherencia de la información durante las actualizaciones en una base de datos concentrada, estos problemas plantean ciertos desafíos. Se propone la descentralización de datos como una posible solución a estos problemas. La descentralización logra:

Mayor grado de simultaneidad de procesamiento debido al equilibrio de carga;
Mejorar el uso de datos en el campo al realizar consultas remotas (remotas);
Costos mas bajos;
Facilidad para administrar bases de datos locales.

Los costos de crear una red, en cuyos nodos se encuentran las estaciones de trabajo (computadoras pequeñas), son mucho más bajos que los costos de crear un sistema similar utilizando una computadora grande. La figura 1.3 muestra el diagrama lógico de una base de datos distribuida.

Figura 1.3. Base de datos de corporaciones distribuida.

Démosle la siguiente definición de una base de datos distribuida.

Base de datos distribuida - es una colección de información, archivos (relaciones) almacenados en diferentes nodos de la red de información y conectados lógicamente de tal manera que conforman un único conjunto de datos (la comunicación puede ser funcional o mediante copias de un mismo archivo). Así, es un conjunto de bases de datos que están interconectadas lógicamente, pero ubicadas físicamente en varias máquinas que forman parte de la misma red informática.

Los requisitos de rendimiento más importantes para una base de datos distribuida son:

Escalabilidad;
Compatibilidad;
Soporte para varios modelos de datos;
Portabilidad;
Transparencia de ubicación;
Autonomía de los nodos de una base de datos distribuida (Site Autonomy);
Procesamiento de solicitudes distribuido;
Ejecución de transacciones distribuidas.
Soporte para un sistema de seguridad homogéneo.

La transparencia de la ubicación permite a los usuarios interactuar con las bases de datos sin saber nada sobre su ubicación. La autonomía de los nodos de bases de datos distribuidos significa que cada base de datos se puede mantener independientemente de las demás. Una consulta distribuida es una consulta (declaración SQL) durante la ejecución de qué objetos (tablas o vistas) de diferentes bases de datos se accede. Al ejecutar transacciones distribuidas, se realiza el control de concurrencia de todas las bases de datos involucradas. Oracle7 utiliza tecnología de transferencia de información de dos fases para realizar transacciones distribuidas.

Las bases de datos que componen una base de datos distribuida no tienen que ser homogéneas (es decir, ser mantenidas por un DBMS) o procesadas en el entorno del mismo sistema operativo y / o en computadoras del mismo tipo. Por ejemplo, una base de datos puede ser una base de datos Oracle en una máquina SUN que ejecuta SUN OS (UNIX), una segunda base de datos puede ser alojada por una base de datos DB2 en un mainframe IBM 3090 con un sistema operativo MVS, y una tercera base de datos puede ser mantenida por SQL / DS también en el mainframe de IBM, pero con el sistema operativo VM. Solo se requiere una condición: todas las máquinas con bases de datos deben ser accesibles a través de la red de la que forman parte.

La principal tarea de una base de datos distribuida - distribución de datos a través de la red y acceso a ellos. Existen las siguientes formas de resolver este problema:

Cada nodo almacena y usa su propio conjunto de datos que está disponible para consultas remotas. Esta distribución está dividida.
Algunos datos que se utilizan con frecuencia en sitios remotos pueden estar duplicados. Esta distribución se llama parcialmente duplicada.
Todos los datos se duplican en cada nodo. Esta distribución se llama completamente duplicada.
Algunos archivos se pueden dividir horizontalmente (se selecciona un subconjunto de registros) o verticalmente (se selecciona un subconjunto de campos de atributos), mientras que los subconjuntos seleccionados se almacenan en diferentes nodos junto con datos sin dividir. Esta distribución se llama dividida (fragmentada).

Al crear una base de datos distribuida, a nivel conceptual, debes resolver las siguientes tareas:

Es necesario tener un diagrama conceptual único de toda la red. Esto proporcionará una transparencia lógica de los datos para el usuario, como resultado de lo cual podrá realizar una solicitud a toda la base de datos, estando detrás de un terminal separado (parece funcionar con una base de datos centralizada).
Se necesita un esquema para ubicar los datos en la red. Esto proporcionará transparencia en la ubicación de los datos, gracias a lo cual el usuario no tiene que especificar dónde enviar la solicitud para obtener los datos requeridos.
Es necesario solucionar el problema de la heterogeneidad de las bases de datos distribuidas. Las bases de datos distribuidas pueden ser homogéneas o heterogéneas en términos de hardware y software. El problema de la heterogeneidad es relativamente fácil de resolver si la base de datos distribuida es heterogénea en el sentido de hardware, pero homogénea en el sentido de software (el mismo DBMS en los nodos). Si se utilizan diferentes DBMS en los nodos de un sistema distribuido, se requieren medios para transformar las estructuras de datos y los lenguajes. Esto debería proporcionar una transformación transparente a través de los nodos de la base de datos distribuida.
Es necesario solucionar el problema de la gestión del diccionario. Para proporcionar todo tipo de transparencia en una base de datos distribuida, necesita programas que gestionen numerosos diccionarios y libros de referencia.
Necesita definir métodos para ejecutar consultas en una base de datos distribuida. Los métodos para ejecutar consultas en una base de datos distribuida difieren de los de bases de datos centralizadas, ya que las partes individuales de las consultas deben ejecutarse en la ubicación de los datos relevantes y los resultados parciales deben pasarse a otros nodos; al mismo tiempo, debe garantizarse la coordinación de todos los procesos.
Es necesario solucionar el problema de la ejecución de consultas en paralelo. Una base de datos distribuida requiere un sofisticado mecanismo de control de concurrencia, que, en particular, debe asegurar la sincronización cuando se actualiza la información, lo que asegura la consistencia de los datos.
Se requiere una metodología desarrollada para la distribución y ubicación de datos, incluida la división, que es uno de los principales requisitos para una base de datos distribuida.

Una de las nuevas áreas de la arquitectura de los sistemas informáticos en desarrollo activo, que es una herramienta poderosa para el procesamiento de información no numérica, es máquinas de base de datos... Las máquinas de base de datos se utilizan para resolver tareas no numéricas como almacenar, buscar y transformar documentos y hechos, y trabajar con objetos. Siguiendo la definición de datos como información digital y gráfica sobre objetos del mundo circundante, se incrusta contenido diferente en el concepto de datos en el procesamiento numérico y no numérico. El procesamiento numérico usa objetos como variables, vectores, matrices, matrices multidimensionales, constantes, etc., mientras que el procesamiento no numérico usa objetos como archivos, registros, campos, jerarquías, redes, relaciones, etc. directamente en información sobre objetos (por ejemplo, un empleado específico o un grupo de empleados), y no en el archivo de empleados como tal. El archivo de empleados no se indexa aquí para seleccionar una persona específica; aquí el contenido de la entrada deseada es más interesante. Por lo general, grandes cantidades de información se someten a un procesamiento no numérico. En varias aplicaciones, puede realizar, por ejemplo, las siguientes operaciones con estos datos:

aumentar el salario de todos los empleados de la empresa;
calcular el interés bancario en las cuentas de todos los clientes;
realizar cambios en la lista de todos los productos en stock;
encontrar el resumen requerido de todos los textos almacenados en la biblioteca o en el sistema de recuperación de información bibliográfica;
encontrar una descripción del contrato requerido en un archivo que contenga documentos legales;
revise todos los archivos que contienen descripciones de patentes y busque una patente (si la hubiera) similar a la propuesta nuevamente.

Implementar el motor de base de datos, paralelo y asociativo la arquitectura como alternativa al monoprocesadorvon Neumannestructura, permitiendo trabajar con grandes cantidades de información en tiempo real.

Las máquinas de bases de datos están ganando importancia en relación con la investigación y aplicación de conceptos de inteligencia artificial como representación del conocimiento, sistemas expertos, inferencia, reconocimiento de patrones, etc.

Almacenes de información. Hoy en día, muchos admiten que ya, la mayoría de las empresas operan varias bases de datos y, para un trabajo exitoso con la información, no solo se requieren diferentes tipos de bases de datos, sino diferentes generaciones de DBMS. Según las estadísticas, cada organización utiliza una media de 2,5 DBMS diferentes. Se hizo evidente la necesidad de "aislar" el negocio de las empresas, o mejor dicho, las personas involucradas en este negocio, de las características tecnológicas de las bases de datos, para brindar a los usuarios una visión única de la información corporativa, independientemente de dónde se encuentre físicamente almacenada. Esto estimuló la aparición de la tecnología de almacenamiento de información ( Almacenamiento de datos, DW).

El principal objetivo de DW es creación de una única representación lógica de los datos contenidos en diferentes tipos de bases de datos o, en otras palabras, un único modelo de datos corporativos.

Una nueva ronda de desarrollo de DW fue posible gracias a la mejora de las tecnologías de la información en general, en particular, la aparición de nuevos tipos de bases de datos basadas en el procesamiento de consultas en paralelo, que a su vez se apoyó en los avances en el campo de las computadoras en paralelo. Fueron creados constructores de consultascon una interfaz gráfica intuitiva, que facilitó la creación de consultas complejas a la base de datos. Varios softwarecapa intermedia (midleware)proporcionó una conexiónentre bases de datos heterogéneas, y finalmente cayó bruscamentedispositivos de almacenamiento.

Un banco de datos puede estar presente en la estructura de una corporación.

Base de datos - un componente funcional y organizativo en los sistemas de control automatizados y los sistemas informáticos y de información, que proporciona soporte de información centralizada para un equipo de usuarios o un conjunto de tareas resueltas en el sistema.

Base de datos se considera un sistema de información y referencia, cuya finalidad principal es:

en la acumulación y mantenimiento en funcionamiento de un conjunto de información que constituye la base de información de todo el sistema automatizado o de un determinado conjunto de tareas resueltas en él;
en la emisión de los datos requeridos por la tarea o usuario;
al proporcionar acceso colectivo a información almacenada;
en asegurar la gestión necesaria del uso de la información contenida en la base de información.

Por lo tanto, un banco de datos moderno es un complejo complejo de software y hardware, que incluye herramientas técnicas, de sistema y de red, bases de datos y DBMS, sistemas de recuperación de información para diversos fines.

V .2. DBMS Y SOLUCIONES ESTRUCTURALES EN SISTEMAS CORPORATIVOS

Sistemas de gestión de bases de datos y conocimientos

Un componente importante de los sistemas de información modernos son los sistemas de gestión de bases de datos (DBMS).

DBMS - un conjunto de software y herramientas lingüísticas destinadas a la creación, mantenimiento y uso de bases de datos.

El sistema de gestión de bases de datos proporciona acceso de los sistemas de procesamiento de datos a las bases de datos. Como ya se señaló, los DBMS adquieren un papel importante en la creación de sistemas de información corporativos y, un papel particularmente importante, en la creación de sistemas de información utilizando recursos de información distribuidos basados en tecnologías informáticas de red modernas.

La característica principal del DBMS moderno es que el DBMS moderno admite tecnologías como:

Tecnología cliente / servidor.
Soporte de idiomas de base de datos. esolenguaje de definición de esquema DB (SDL - Lenguaje de definición de esquemas),lenguaje de manipulación de datos (DML), lenguajes integrados SQL (lenguaje de cola estructurado), QDB (consulta por ejemplo) y QMF (función de gestión de consultas ) Es una herramienta de generación de informes y especificación de consultas periféricas DB 2, etc.;
Gestión directa de datos en memoria externa.
Gestión de búferes RAM.
Gestión de transacciones. OLTP - tecnología (Procesamiento de transacciones en línea), OLAP - tecnología (Procesamiento de análisis en línea) para DW.
Garantice la protección e integridad de los datos. El uso del sistema está permitido solo a los usuarios que tienen derecho a acceder a los datos. Cuando los usuarios realizan operaciones con datos, se mantiene la coherencia de los datos almacenados (integridad). Esto es importante en los sistemas de información corporativos multiusuario.
Periodización.

El DBMS moderno debe garantizar el cumplimiento de los requisitos de la base de datos enumerados anteriormente. Además, deberán cumplir con los siguientes principios:

Independencia de datos.
Versatilidad. El DBMS debe tener un potente soporte de modelo de datos conceptual para mostrar vistas lógicas personalizadas.
Compatibilidad. El DBMS debe permanecer operativo con el desarrollo de software y hardware.
Redundancia de datos. A diferencia de los sistemas de archivos, una base de datos debe ser una colección única de datos integrados.
Protección de Datos. El DBMS debe brindar protección contra el acceso no autorizado.
Integridad de los datos. El DBMS debe evitar que los usuarios rompan la base de datos.
Gestión de trabajo simultáneo. El DBMS debe proteger la base de datos de inconsistencias en el modo de acceso compartido. Para garantizar un estado coherente de la base de datos, todas las solicitudes (transacciones) de los usuarios deben ejecutarse en un orden específico.
El DBMS debe ser universal. Debe admitir diferentes modelos de datos sobre una única base lógica y física.
El DBMS debe admitir bases de datos centralizadas y distribuidas y, por lo tanto, convertirse en un vínculo importante en las redes informáticas.

Considerando un DBMS como una clase de productos de software enfocados en el mantenimiento de bases de datos en sistemas automatizados, podemos distinguir dos características más esenciales que determinan los tipos de DBMS. Según ellos, un DBMS puede verse desde dos puntos de vista:

sus capacidades en relación con bases de datos distribuidas (corporativas);
su relación con el tipo de modelo de datos implementado en el DBMS.

En relación con las bases de datos corporativas (distribuidas), los siguientes tipos de DBMS se pueden distinguir convencionalmente:

DBMS de "escritorio". Estos productos se centran principalmente en trabajar con datos personales (datos de "escritorio"). Tienen conjuntos de comandos para compartir bases de datos comunes, pero de tamaño pequeño (como una oficina pequeña). En primer lugar, es un DBMS como Assess, dBASE, Paradox, EohPgo. Por qué Assess, dBASE, Paradox, EohPgo tienen un acceso deficiente a los datos corporativos. El caso es que no existe una manera fácil de superar la barrera entre los datos personales y corporativos. Y el caso no es ni siquiera que el mecanismo del DBMS de datos personales (o pequeña oficina) se centre en acceder a los datos a través de muchas pasarelas, productos de interconexión, etc. El problema es que estos mecanismos suelen estar asociados con transferencias de archivos completas y la falta de compatibilidad con índices bifurcados, lo que hace que las colas de servidor prácticamente se atasquen en sistemas grandes.
DBMS multiusuario de alto rendimiento especializado. Dichos DBMS se caracterizan por la presencia de un núcleo de sistema multiusuario, un lenguaje de manipulación de datos y las siguientes funciones típicas de los DBMS multiusuario desarrollados:
organización del grupo de amortiguadores;
la presencia de un sistema para procesar colas de transacciones;
la presencia de mecanismos para el bloqueo de datos multiusuario;
registro de transacciones;
la disponibilidad de mecanismos de control de acceso.

Estos son DBMS como Oracle, DB2, SQL / Server, Informix, Sybase, ADABAS, Titanium y otros brindan un amplio servicio para el procesamiento de bases de datos corporativas.

Cuando se trabaja con bases de datos, se utiliza el mecanismo de transacción.

Transacción Es una unidad lógica de trabajo.

Transacción es una secuencia de declaraciones de manipulación de datos ejecutadascomo un todo(todo o nada) y traduciendo la base de datosde un estado holístico a otro estado holístico.

Una transacción tiene cuatro propiedades importantes conocidas como propiedades ASID:

(A) Atomicidad ... Una transacción se ejecuta como una operación atómica: se ejecuta toda la transacción o no se ejecuta por completo.
(C) Coherencia... Una transacción mueve una base de datos de un estado consistente (consistente) a otro estado consistente (consistente). Dentro de una transacción, se puede violar la coherencia de la base de datos.
(I) Aislamiento ... Las transacciones de diferentes usuarios no deben interferir entre sí (por ejemplo, como si se ejecutaran estrictamente por turno).
(E) Durabilidad... Si la transacción se completa, los resultados de su trabajo deben guardarse en la base de datos, incluso si en el siguiente momento el sistema falla.

La transacción generalmente comienza automáticamente desde el momento en que el usuario se conecta al DBMS y continúa hasta que ocurre uno de los siguientes eventos:

Se emite el comando COMMIT WORK.
Se emitió el comando ROLLBACK WORK.
El usuario se ha desconectado del DBMS.
Hubo una falla del sistema.

Para el usuario, suele llevar carácter atómico... De hecho, este es un mecanismo complejo de interacción entre el usuario (aplicación) y la base de datos. El software de sistemas empresariales utiliza un motor de procesamiento de transacciones en tiempo real (Sistemas de procesamiento de transacciones en línea, OLTP), en particular programas de contabilidad, software para recibir y procesar pedidos de clientes, aplicaciones financieras, producen mucha información. Estos sistemas están diseñados (y adecuadamente optimizados) para manejar grandes cantidades de datos, transacciones complejas y operaciones intensivas de lectura / escritura.

Desafortunadamente, la información colocada en las bases de datos de los sistemas OLTP no es muy adecuada para el uso de usuarios comunes (debido al alto grado de normalización de tablas, formatos específicos de presentación de datos y otros factores). Por lo tanto, los datos de diferentes canales de información se envían (en el sentido, se copian) a almacén de almacenamiento, clasificación y posterior entrega al consumidor. En tecnología de la información, el papel de los almacenes lo desempeñanalmacenamientos de información.

Entrega de información al usuario final: sistemas de procesamiento de datos analíticos en tiempo real (Procesamiento analítico en línea, OLAP)que brindan un acceso extremadamente fácil a los datos a través de métodos convenientes para generar consultas y analizar resultados. En los sistemas OLAP, el valor de un producto de información aumenta debido al uso de varios métodos de análisis y procesamiento estadístico. Además, estos sistemas están optimizados en cuanto a la velocidad de extracción de datos, recolección de información generalizada y están dirigidos a usuarios comunes (tienen una interfaz intuitiva). Si Sistema OLTP da respuestas a preguntas simples como "¿cuál fue el nivel de ventas del producto N en la región M en enero de 199x?", luego Sistemas OLAP listo para solicitudes de usuarios más complejas, por ejemplo: "Proporcionar un análisis de las ventas del producto N en todas las regiones de acuerdo con el plan para el segundo trimestre en comparación con los dos años anteriores".

Arquitectura cliente / servidor

En sistemas modernos procesamiento de información distribuida, la tecnología ocupa un lugar central Servidor de cliente. En el sistema arquitectura cliente-servidorel procesamiento de datos se divide entre la computadora cliente y la computadora servidor, la comunicación entre los cuales tiene lugar a través de la red. Esta separación del procesamiento de datos se basa en la agrupación de funciones. Normalmente, una computadora servidor de base de datos se dedica a realizar operaciones de base de datos y una computadora cliente ejecuta programas de aplicación. La Figura 2.1 muestra un sistema de arquitectura cliente-servidor simple que incluye una computadora que actúa como servidor y otra computadora que actúa como su cliente. Cada máquina realiza diferentes funciones y tiene sus propios recursos.

		Base de datos
Computadora servidor
La red
PC compatible con IBM	PC compatible con IBM	PC compatible con IBM
		Aplicaciones

Arroz. 2.1. Sistema de arquitectura cliente-servidor

La función principal de la computadora cliente es ejecutar la aplicación (interfaz de usuario y lógica de presentación) y comunicarse con el servidor cuando la aplicación lo requiera.

Servidor Es un objeto (computadora) que brinda servicios a otros objetos a pedido de éstos.

Como se desprende del término en sí, la función principal de la computadora servidor es satisfacer las necesidades del cliente. El término "Servidor" se utiliza para designar dos grupos diferentes de funciones: un servidor de archivos y un servidor de base de datos (en adelante, estos términos significan, según el contexto, software que implementa los grupos de funciones especificados o computadoras con este software). . Los servidores de archivos no están diseñados para realizar operaciones de bases de datos, su función principal es compartir archivos entre múltiples usuarios, es decir, proporcionando acceso simultáneo de muchos usuarios a archivos en el servidor de archivos de la computadora. Un ejemplo de servidor de archivos es el sistema operativo NetWare de Novell. El servidor de la base de datos se puede instalar y operar en una computadora servidor de archivos. Oracle DBMS en forma de NLM (módulo cargable de red) se ejecuta en el entorno NetWare en el servidor de archivos.

Un servidor de red local debe tener los recursos apropiados para su propósito funcional y las necesidades de la red. Tenga en cuenta que en relación con el enfoque en el enfoque de sistemas abiertos, es más correcto hablar de servidores lógicos (es decir, un conjunto de recursos y software que brindan servicios sobre estos recursos), que no están necesariamente ubicados en diferentes computadoras. Una característica de un servidor lógico en un sistema abierto es que si, por razones de eficiencia, es recomendable mover el servidor a una computadora separada, entonces esto se puede hacer sin necesidad de ninguna modificación, tanto de sí mismo como de las aplicaciones. que lo usan.

Uno de los requisitos importantes del servidor es que el sistema operativo que aloja el servidor de la base de datos debe ser multitarea (y preferiblemente, pero no necesariamente multiusuario). Por ejemplo, un DBMS de Oracle instalado en una computadora personal con un sistema operativo MS-DOS (o PC-DOS) que no cumple con el requisito de multitarea no se puede utilizar como servidor de base de datos. Y la misma base de datos Oracle instalada en una computadora con un sistema operativo OS / 2 multitarea (aunque no multiusuario) puede ser un servidor de base de datos. Muchos tipos de UNIX, MVS, VM y algunos otros sistemas operativos son multitarea y multiusuario.

Computación distribuída

El término "computación distribuida" se usa a menudo para referirse a dos conceptos diferentes, aunque complementarios:

Base de datos distribuida;
Procesamiento de datos distribuidos.

La aplicación de estos conceptos permite organizar el acceso a la información almacenada en múltiples máquinas para los usuarios finales utilizando diferentes medios.

Hay muchos tipos de servidores:

Servidor de base de datos;
Servidor de impresión;
Servidor de acceso remoto;
Servidor de fax;
Servidor web, etc.

En el corazón de la tecnología subyacente se encuentra Cliente / Servidor son tecnologías tan básicas como:

Tecnologías de sistemas operativos, el concepto de interacción de sistemas abiertos, la creación de entornos orientados a objetos para el funcionamiento de programas;
Tecnologías de telecomunicaciones;
Tecnologías de red;
Tecnologías de interfaz gráfica de usuario ( GUI);
Etc.

Ventajas de la tecnología cliente-servidor:

La tecnología cliente / servidor permite la informática en entornos informáticos heterogéneos. Independencia de plataforma: acceso a entornos de red heterogéneos que incluyen diferentes tipos de computadoras con diferentes sistemas operativos.
Independencia de las fuentes de datos: acceso a la información de bases de datos heterogéneas. Ejemplos de tales sistemas son DB2, SQL / DS, Oracle, Sybase.
Equilibrio de carga entre cliente y servidor.
Realice cálculos donde sea más eficiente;
Proporcionar la capacidad de escalar de manera eficiente;
Computación multiplataforma... La informática multiplataforma se define simplemente como la implementación de tecnologías en entornos informáticos heterogéneos. Aquí se deben proporcionar las siguientes posibilidades:
La aplicación debe ejecutarse en múltiples plataformas;
En todas las plataformas, debe tener la misma interfaz y lógica de trabajo;
La aplicación debe integrarse con el entorno operativo nativo;
Debería comportarse igual en todas las plataformas;
Se le debe proporcionar un soporte simple y consistente.

 Computación distribuída. La computación distribuida implica la distribución del trabajo entre varias computadoras (aunque la computación distribuida es un concepto más amplio).

 Reducción de personal. La reducción es la migración de aplicaciones de mainframe a plataformas informáticas pequeñas.

Costos reducidos de infraestructura y hardware. Rentable: la disponibilidad de equipos informáticos de bajo coste y la creciente proliferación de redes de área local hacen que la tecnología cliente-servidor sea más rentable que otras tecnologías de procesamiento de datos. El equipo se puede actualizar tan pronto como surja la necesidad.

 Reducir el tiempo total de ejecución de la aplicación;

 Reducir el uso de memoria del cliente;

 Reducir el tráfico de la red.

Capacidad para trabajar con multimedia: hasta la fecha, se han creado muchos programas multimedia para PC. No existen tales programas para la configuración del host de la terminal o son muy costosos.
La capacidad de atraer grandes recursos informáticos para las operaciones de la base de datos: dado que las aplicaciones se ejecutan en las computadoras cliente, se liberan recursos adicionales (en comparación con la configuración terminal-host) en la computadora servidor para las operaciones de la base de datos, como los recursos informáticos del procesador central y memoria operativa.
Mejor productividad del programador: la productividad del programador aumenta mediante el uso de herramientas como SQL * Forms y CASE, que le permiten desarrollar aplicaciones más rápido que los lenguajes de programación como C, PL1 o COBOL.
Mayor productividad del usuario final: a estas alturas, muchos usuarios finales han dominado sistemas como Lotus, Paradox, Word Perfect, Harvard Graphics y más.

La interfaz del lado del servidor está definida y fija. Por lo tanto, es posible crear nuevas partes de cliente de un sistema existente (un ejemplo de interoperabilidad a nivel del sistema).

Arroz. 2.2. Ilustración del acceso de un cliente a un recurso compartido de servidor.

Cómo implementar la tecnología cliente-servidor

A continuación se analiza la instalación de un sistema basado en tecnología cliente-servidor y capaz de realizar procesamiento de datos distribuidos. Se requiere el siguiente hardware y software de computadora:

ordenador servidor de base de datos;
computadoras cliente;
red de comunicacion;
software de red;
Software de la aplicacion.

Lenguaje SQL ... Lenguaje de consulta de alto nivel - SQL (lenguaje de consulta estructurado ) sirve para implementar consultas a bases de datos, como YAMD, YOD y PNP y se adopta como estándar. Idioma SQL fue adoptado originalmente como el lenguaje de datos de los productos de software de la empresa IBM y DBMS relacional YAMD SYSTEM R de IBM ... Una característica importante del idioma. SQL radica en el hecho de que un mismo lenguaje se representa a través de dos interfaces diferentes, a saber: a través de una interfaz interactiva y a través de una interfaz de programación de aplicaciones (dinámica SQL). SQL dinámico consta de muchas funciones de lenguaje integradas SQL , previsto específicamente para la construcción de aplicaciones interactivas, donde una aplicación interactiva se entiende como un programa que está escrito para soportar el acceso a la base de datos del usuario final que trabaja en el terminal interactivo. Idioma SQL proporciona las funciones de definir, manipular y administrar los datos de la base de datos y es transparente para el usuario desde el punto de vista del DBMS implementado.

Arroz. 2.3. Esquema de ejecución de consultas de usuarios a bases de datos distribuidas.

La estructura interna de las bases de datos está determinada por los modelos de datos utilizados. El modelo conceptual tiene más capacidades de abstracción y una semántica más rica que los modelos externos. Los modelos externos a menudo se denominan modelos sintácticos u operativos, refiriéndose a la naturaleza sintáctica del control y uso como medio de interacción del usuario con la base de datos. En el Modelado de Información, existen diferentes niveles de abstracción, desde el modelo conceptual hasta el modelo de datos físicos, que afectan la arquitectura del DBMS.

El modelo de datos tiene tres componentes:

La estructura de datos a representar desde el punto de vista del usuario de la base de datos.
Operaciones válidas realizadas sobre la estructura de datos. Es necesario poder trabajar con esta estructura utilizando varias operaciones de NOD y NAM. Una estructura rica no tiene valor si no hay forma de manipular su contenido.
Restricciones de control de integridad. El modelo de datos debe contar con medios para mantener su integridad y protegerlo. Como ejemplo, considere las siguientes dos restricciones:
Cada subárbol debe tener un nodo de origen. Las bases de datos jerárquicas no pueden almacenar nodos secundarios sin un nodo de origen.
Con respecto a una base de datos relacional, no puede haber tuplas idénticas. Para un archivo, este requisito requiere que todos los registros sean únicos.

Una de las características más importantes de un DBMS es la capacidad de vincular objetos.

Existen los siguientes tipos de vínculos entre objetos:

Uno a uno (1: 1)... Un objeto de un conjunto se puede asociar con un objeto de otro conjunto.
Uno a varios (1: M)... Un objeto de un conjunto se puede asociar con muchos objetos de otro conjunto.
Muchos a muchos (M: N)... Un objeto de un conjunto se puede asociar con muchos objetos de otro conjunto, pero al mismo tiempo un objeto de otro conjunto se puede asociar con muchos objetos del primer conjunto.
Ramificado ... Un objeto de un conjunto puede asociarse con objetos de muchos conjuntos.
Recursivo ... Un objeto de un conjunto dado puede estar vinculado por un objeto del mismo conjunto.

Existen los siguientes modelos de datos básicos:

Modelo de datos relacionales.
Modelo de datos jerárquico.
Modelo de datos de red incompleto.
Modelo de datos CODASYL.
Modelo de datos de red extendido.

V .3. TECNOLOGÍAS INTERNET / INTRANET Y SOLUCIONES CORPORATIVAS DE ACCESO A BASES DE DATOS

El principal problema de los sistemas basados en la arquitectura cliente-servidor es que, de acuerdo con el concepto de sistemas abiertos, se requiere que sean móviles en la clase más amplia posible de soluciones hardware y software de sistemas abiertos. Incluso si nos limitamos a las redes de área local basadas en UNIX, diferentes redes utilizan diferentes equipos y protocolos de comunicación. Los intentos de crear sistemas que admitan todos los protocolos posibles conducen a su sobrecarga con los detalles de la red en detrimento de la funcionalidad.

Un aspecto aún más complejo de este problema está asociado con la posibilidad de utilizar diferentes representaciones de datos en diferentes nodos de una red local heterogénea. Diferentes computadoras pueden tener diferentes direcciones, representación numérica, codificación de caracteres, etc. Esto es especialmente importante para servidores de alto nivel: telecomunicaciones, informática, bases de datos.

Una solución común al problema de la movilidad en sistemas basados en una arquitectura cliente-servidor es confiar en paquetes de software que implementan protocolos de llamada a procedimiento remoto (RPC). Con estas herramientas, una llamada a un servicio en un sitio remoto parece una llamada de procedimiento normal. Las herramientas RPC, que naturalmente contienen toda la información sobre los detalles del hardware de la red local y los protocolos de red, traducen la llamada en una secuencia de interacciones de red. Por lo tanto, los detalles del entorno de red y los protocolos están ocultos para el programador de aplicaciones.

Cuando se llama a un procedimiento remoto, los programas RPC convierten los formatos de datos del cliente a formatos intermedios independientes de la máquina y luego los convierten a formatos de datos del servidor. Al pasar los parámetros de respuesta, se realizan transformaciones similares.

Otros trabajos similares que te pueden interesar. Wshm>
6914.		Concepto de base de datos	11,56 KB
	La base de datos se presenta en forma objetiva, un conjunto de materiales independientes de artículos de cálculo de actos normativos de decisiones judiciales y otros materiales similares sistematizados de tal manera que estos materiales se pueden encontrar y procesar utilizando una computadora electrónica Código Civil de la Federación de Rusia Federación Art. Una base de datos organizada de acuerdo con ciertas reglas y mantenida en la memoria de la computadora es un conjunto de datos que caracterizan el estado actual de algunos ...
8064.		Bases de datos distribuidas	43,66 KB
	Bases de datos distribuidas Una base de datos distribuida RDB se entiende como un conjunto de datos compartidos interconectados lógicamente que se distribuyen físicamente en diferentes nodos de una red informática. El acceso a los datos no debe depender de la presencia o ausencia de réplicas de datos. El sistema debe determinar automáticamente los métodos para realizar la conexión de fusión de datos, el canal de red es capaz de hacer frente a la cantidad de información transmitida y el nodo tiene suficiente poder de procesamiento para unirse a las tablas. El RDBMS debe ser capaz de ...
20319.		BASES DE DATOS Y SU PROTECCIÓN	102,86 KB
	Las bases de datos en línea surgieron a mediados de la década de 1960. Las operaciones en las bases de datos operativas se procesaron de forma interactiva utilizando terminales. Las organizaciones de registros secuenciales de índices simples evolucionaron rápidamente a un modelo de registro orientado a conjuntos más poderoso. Charles Bachmann recibió el Premio Turing por liderar el Grupo de tareas de base de datos (DBTG), que desarrolló un lenguaje estándar para la descripción y manipulación de datos.
5031.		Biblioteca de desarrollo de bases de datos	11,72 MB
	Tecnología de diseño de bases de datos. Determinar relaciones entre entidades y crear un modelo de datos. Las ideas principales de la tecnología de la información moderna se basan en el concepto según el cual los datos deben organizarse en bases de datos para reflejar adecuadamente el mundo real cambiante y satisfacer las necesidades de información de los usuarios. Estas bases de datos se crean y operan bajo el control de sistemas de software especiales llamados sistemas de administración de bases de datos DBMS.
13815.		MODELO DE BASE DE DATOS JERÁRQUICA	81.62 KB
	Las ideas principales de la tecnología de la información moderna se basan en el concepto de bases de datos, según el cual la base de la tecnología de la información son los datos organizados en bases de datos que reflejan adecuadamente el estado de un área temática en particular y brindan al usuario información relevante en esta área temática. Debe reconocerse que los datos son ...
14095.		Desarrollo de bases de datos de bibliotecas	11,72 MB
	El aumento en el volumen y la complejidad estructural de los datos almacenados, la expansión del círculo de usuarios de los sistemas de información han llevado al uso generalizado del DBMS relacional (tabular) más conveniente y relativamente fácil de entender.
5061.		Creación de base de datos policlínica	2,4 MB
	El desarrollo de la tecnología informática y la tecnología de la información ha brindado oportunidades para la creación y el uso generalizado de sistemas de información automatizados (AIS) para diversos fines. Se están desarrollando e implementando sistemas de información para la gestión de instalaciones económicas y técnicas.
13542.		Bases de datos de información geológica	20,73 KB
	Recientemente, la introducción de tecnologías informáticas y, en particular, bases de datos, en el campo científico se ha producido rápidamente. Este proceso tampoco pasa por alto la geología, ya que es en las ciencias naturales donde existe la necesidad de almacenar y procesar grandes cantidades de información.
9100.		Base de datos. Conceptos básicos	26,28 KB
	Una base de datos es una colección de información sobre objetos específicos del mundo real en cualquier área temática de economía, administración, química, etc. El propósito de un sistema de información no es solo el almacenamiento de datos sobre objetos, sino también la manipulación de estos datos. , teniendo en cuenta las conexiones entre objetos. Cada objeto se caracteriza por un conjunto de datos de propiedades, que se denominan atributos en la base de datos.
5240.		Creación de la base de datos "Oficina del decano"	1,57 MB
	La base de datos (DB) es un conjunto de datos interconectados almacenados juntos en un medio de almacenamiento externo de una computadora, con una organización de este tipo y una redundancia mínima que les permite ser utilizados de manera óptima para una o varias aplicaciones.

El propósito de la conferencia

Después de estudiar el material de esta conferencia, sabrá:

qué modelo de datos empresariales ;
como convertir modelo de datos empresariales en el modelo de almacenamiento de datos;
elementos principales modelo de datos corporativos ;
capas de presentación del modelo de datos corporativos ;
un algoritmo para transformar un modelo de datos empresarial en un modelo de almacenamiento de datos multidimensional ;

y aprender a:

Desarrollar modelos de almacenamiento de datos basados en modelo de datos corporativos organizaciones;
diseñar un esquema en estrella usando herramientas CASE;
tablas de partición modelo multidimensional utilizando herramientas CASE.

Modelo de datos empresariales

Introducción

El núcleo de cualquier HD es su modelo de datos. Sin un modelo de datos, será muy difícil organizar los datos en el HD. Por lo tanto, los desarrolladores de CD deberían dedicar tiempo y esfuerzo a desarrollar dicho modelo. El desarrollo del modelo HD recae sobre los hombros del diseñador HD.

En comparación con el diseño de sistemas OLTP, la metodología de diseño de CD tiene una serie de características distintivas asociadas con la orientación de las estructuras de datos de almacenamiento para resolver los problemas de análisis y soporte de información del proceso de toma de decisiones. El modelo de datos HD debería proporcionar una solución eficaz precisamente a estos problemas.

El punto de partida en el diseño de CD puede ser el llamado modelo de datos empresariales(modelo de datos corporativos o modelo de datos empresariales, EDM), que se crea en el proceso de diseño de los sistemas OLTP de una organización. Al diseñar modelo de datos corporativos Por lo general, se intenta crear una estructura de datos basada en operaciones comerciales que recopile y sintetice todas las necesidades de información de una organización.

Por lo tanto, modelo de datos empresariales contiene la información necesaria para construir un modelo de CD. Por lo tanto, en la primera etapa, si tal modelo existe en la organización, el diseñador de HD puede iniciar el diseño de HD resolviendo el problema de transformación modelo de datos corporativos en el modelo HD.

Modelo de datos empresariales

Cómo resolver el problema de la transformación modelo de datos corporativos en el modelo HD? Para resolver este problema, debe tener este modelo, es decir modelo de datos corporativos debe ser construido y documentado... Y necesitas entender qué de este modelo y cómo debería transformarse en el modelo HD.

Aclaremos desde el punto de vista de un diseñador de CD el concepto modelo de datos corporativos. Debajo modelo de datos corporativos Comprender una descripción estructurada de varios niveles de las áreas temáticas de una organización, las estructuras de datos de las áreas temáticas, los procesos y procedimientos comerciales, los flujos de datos organizacionales, los diagramas de estado, las matrices de procesos de datos y otras representaciones de modelos que se utilizan en las actividades de la organización. Así, en el sentido más amplio de la palabra, modelo de datos empresariales es un conjunto de modelos de varios niveles que caracterizan (modelan en algún nivel abstracto) las actividades de una organización, es decir contenido modelo corporativo depende directamente de qué construcciones de modelo se incluyeron en él en una organización determinada.

Los elementos principales modelo de datos corporativos están:

descripción de las áreas temáticas de la organización (definición de áreas de actividad);
relaciones entre las áreas temáticas definidas anteriormente;
modelo de datos de información (modelo ERD o modelo entidad-relación);
descripción para cada área temática:
- claves de entidad;
- atributos de entidad;
- subtipos y supertipos;
- relaciones entre entidades;
- agrupar atributos;
- relaciones entre áreas temáticas;
modelo funcional o de procesos de negocio;
diagramas de flujo de datos;
diagramas de estado;
Otros modelos.

Por lo tanto, modelo de datos empresariales contiene entidades, atributos y relaciones que representan las necesidades de información de una organización. En la Fig. 16.1 muestra los elementos principales modelo de datos corporativos.

Niveles de presentación del modelo de datos empresariales

El modelo de datos empresariales se subdivide según las áreas temáticas, que representan grupos de entidades relacionadas con el apoyo de necesidades comerciales específicas. Algunas áreas temáticas pueden cubrir funciones comerciales específicas, como la gestión de contratos, mientras que otras pueden incluir entidades que describen productos o servicios.

Cada modelo lógico debe corresponder al dominio existente modelo de datos corporativos... Si el modelo lógico no cumple con este requisito, se le debe agregar un modelo de dominio.

Un modelo de datos empresariales suele tener varios niveles de presentación. De hecho nivel alto(nivel alto) modelo de datos corporativos hay una descripción de las principales áreas temáticas de la organización y sus relaciones a nivel de entidad. En la Fig. 16.2 es un fragmento modelo de datos corporativos nivel superior.

Arroz. 16.2.

El diagrama que se muestra en la figura presenta cuatro áreas temáticas: "Comprador" ( Cliente), "Cheque" ( cuenta), "Pedido" ( Pedido) y "Producto" ( Producto). Como regla, solo conexiones directas entre áreas temáticas, que, por ejemplo, registran el siguiente hecho: el comprador paga la factura del pedido de mercancías. Detalles y relaciones indirectas en este nivel modelo corporativo no mostrado.

En el siguiente, nivel medio(nivel medio) modelo de datos corporativos Se muestra información detallada sobre objetos de áreas temáticas, es decir, claves y atributos de entidad, sus relaciones, subtipos y supertipos, etc. Para cada dominio del modelo de nivel superior, hay un modelo de nivel medio. En la Fig. 16.3 muestra el nivel medio de presentación modelo corporativo para un fragmento del área temática "Orden".

De la fig. 16.3 se puede ver que el área temática "Orden" ( Pedido) incluye varias entidades, definidas a través de sus atributos, y las relaciones entre ellas. El modelo presentado le permite responder preguntas tales como la fecha del pedido, quién hizo el pedido, quién envió el pedido, quién recibe el pedido y varias otras. En el diagrama anterior, se puede ver que en esta organización hay dos tipos de pedidos: pedidos para una promoción ( Comercial) y pedidos al por menor ( Venta minorista).

Darse cuenta de modelo de datos empresariales puede representar varios aspectos de las actividades de la organización y con diversos grados de detalle e integridad. Si modelo corporativo representa todos los aspectos de las actividades de la organización, también se llama modelo de datos de la organización(modelo de datos empresariales).

Desde el punto de vista del diseño de un CD, un factor importante a la hora de decidir crear un modelo de CD a partir de modelo de datos corporativos es el estado lo completo modelo de datos corporativos.

El modelo de datos corporativos de la organización tiene la característica de evolución, es decir está en constante desarrollo y mejora. Algunas áreas temáticas modelo de datos corporativos puede estar bien desarrollado, para algunos es posible que el trabajo aún no haya comenzado. Si un fragmento del área temática no se ha resuelto en modelo de datos corporativos, entonces no hay forma de utilizar este modelo como punto de partida para el diseño de CD.

Grado de finalización modelo corporativo se puede nivelar en el diseño de CD de la siguiente manera. Dado que el proceso de desarrollo de HD generalmente se divide en el tiempo en una secuencia de etapas, el proceso de su diseño se puede sincronizar con proceso de finalización desarrollo de fragmentos individuales modelo de datos corporativos Organizaciones.

En el más bajo capa de presentación del modelo de datos corporativos información sobre las características físicas de los objetos de la base de datos correspondientes a modelo de datos lógicos medio capa de presentación del modelo de datos corporativos.

Zaitsev S.L., Ph.D.

Grupos repetidos

Los grupos duplicados son atributos para los que una sola instancia de una entidad puede tener más de un valor. Por ejemplo, una persona puede tener más de una habilidad. Si, en términos de requisitos comerciales, necesitamos conocer el nivel de habilidad de cada uno, y cada persona solo puede tener dos habilidades, podemos crear la entidad que se muestra en la Fig. 1.6. Aquí está la entidad UNA PERSONA con dos atributos para almacenar habilidades y nivel de habilidad para cada uno.

Arroz. 1.6. Este ejemplo usa grupos repetidos.

El problema con los grupos repetidos es que no podemos saber exactamente cuántas habilidades puede tener una persona. En la vida real, algunas personas tienen una habilidad, algunas tienen varias y algunas aún no tienen ninguna. La figura 1.7 muestra el modelo reducido a la primera forma normal. Tenga en cuenta el agregado ID de habilidad que cada uno identifica de forma única HABILIDAD.

Arroz. 1.7. Modelo reducido a la primera forma normal.

Un hecho en un solo lugar

Si el mismo atributo está presente en más de una entidad y no es una clave externa, este atributo se considera redundante. El modelo lógico no debe contener datos redundantes.

La redundancia requiere espacio adicional, pero si bien la eficiencia de la memoria es importante, el problema real está en otra parte. Asegurarse de que los datos redundantes estén sincronizados es una sobrecarga y siempre corre el riesgo de valores conflictivos.

En el ejemplo anterior HABILIDAD depende de Identificación de la persona y de ID de habilidad. Esto significa que no tendrás HABILIDAD hasta que aparece UNA PERSONA, poseer esta habilidad. Esto también dificulta el cambio del nombre de la habilidad. Es necesario encontrar cada entrada con el Nombre de la habilidad y cambiarlo por cada Persona que posee esta habilidad.

La figura 1.8 muestra el modelo en la segunda forma normal. Tenga en cuenta que la entidad agregada HABILIDAD y el atributo TÍTULO la habilidad se transfiere a esta entidad. El nivel de habilidad permaneció, respectivamente, en la intersección PERSONAS y HABILIDAD.

Arroz. 1.8. En la segunda forma normal, el grupo repetido se mueve a otra entidad. Esto proporciona la flexibilidad de agregar la cantidad requerida de habilidades y cambiar el nombre de la habilidad o la descripción de la habilidad en un solo lugar.

Cada atributo depende de la clave

Cada atributo de una entidad debe depender de la clave principal de esa entidad. En el ejemplo anterior Nombre de la escuela y Área geográfica presente en la mesa UNA PERSONA pero no describa a la persona. Para lograr la tercera forma normal, debe mover los atributos a la entidad, donde dependerán de la clave. Gráfico 1.9. muestra el modelo en la tercera forma normal.

Arroz. 1.9. En tercera forma normal Nombre de la escuela y Región geográfica transferidos a entidad, donde sus valores dependen de la clave.

Relaciones de muchos a muchos

Relación muchos a muchos reflejar la realidad del mundo circundante. Tenga en cuenta que en la Figura 1.9, hay una relación de muchos a muchos entre PERSONA y COLEGIO... La actitud refleja con precisión el hecho de que UNA PERSONA puede estudiar en muchos ESCUELAS y en COLEGIO puedo aprender mucho PERSONA. Para lograr la cuarta forma normal, se crea una entidad asociativa que elimina la relación monogía-a-muchos al generar una entrada separada para cada combinación única de escuela y persona. La figura 1.10 muestra el modelo en cuarta forma normal.

Arroz. 1.10. En cuarta forma normal, una relación monogo-a-muchos entre PERSONA y COLEGIO resuelto mediante la introducción de una entidad asociativa, en la que se asigna una entrada separada para cada combinación única ESCUELAS y PERSONAS.

Definiciones formales de formas normales.

Las siguientes definiciones de formas normales pueden parecer abrumadoras. Piense en ellos simplemente como fórmulas para lograr la normalización. Las formas normales se basan en el álgebra relacional y pueden interpretarse como transformaciones matemáticas. Aunque este libro no está dedicado a una discusión detallada de las formas normales, se anima a los modeladores a profundizar en el tema.

En una relación R dada, el atributo Y depende funcionalmente del atributo X. En forma simbólica, RX -> RY (léase "RX define funcionalmente RY") - si y solo si cada valor de X en R está asociado con exactamente uno valor de Y en R (en cualquier momento dado). Los atributos X e Y pueden ser compuestos (Fecha CJ. Introducción a los sistemas de bases de datos. 6ª edición. Ed. Williams: 1999, 848 págs.).

La relación R corresponde a la primera forma normal (1NF) si y solo si todos los dominios que le pertenecen contienen solo valores atómicos (Fecha, ibid.).

Una relación R corresponde a la segunda forma normal (2NF) si y solo si corresponde a 1NF, y cada atributo que no es clave es completamente dependiente de la clave primaria (Fecha, ibid.).

Una relación R corresponde a la tercera forma normal (3NF) si y solo si corresponde a 2NF, y cada atributo que no es clave no depende transitivamente de la clave primaria (Fecha, ibid.).

La relación R corresponde a la forma normal de Boyes-Codd (BCNF) si y solo si cada determinante es candidato para usarse como clave.

NOTA A continuación se muestra una breve explicación de algunas de las abreviaturas utilizadas en las definiciones de Date.

MVD (dependencia de valores múltiples) es una dependencia de valores múltiples. Se usa solo para entidades con tres o más atributos. En una dependencia de varios valores, el valor del atributo depende solo de una parte de la clave principal.

FD (dependencia funcional) - dependencia funcional. Con la dependencia funcional, el valor de un atributo depende del valor de otro atributo que no es parte de la clave primaria.

JD (dependencia de unión) es una dependencia de unión. Con una dependencia de unión, la clave principal de la entidad principal se remonta al menos a los descendientes del tercer nivel, mientras se conserva la capacidad de ser utilizada en la unión por la clave original.

La relación corresponde a la cuarta forma normal (4NF) si y solo si hay un MVD en R, por ejemplo A®®B. En este caso, todos los atributos de R dependen funcionalmente de A. En otras palabras, en R solo hay dependencias (FD o MVD) de la forma K®X (es decir, la dependencia funcional del atributo X del candidato para su uso como clave K). En consecuencia, R cumple con los requisitos de 4NF si cumple con BCNF y todos los MVD son en realidad FD (Fecha, ibid.).

Para la quinta forma normal, la relación R satisface la dependencia de unión (JD) * (X, Y,…, Z) si y solo si R es equivalente a sus proyecciones sobre X, Y, ..., Z, donde X, Y, ..., Z es un subconjunto del conjunto de atributos R.

Hay muchas otras formas normales para tipos de datos complejos y situaciones específicas que están más allá del alcance de esta discusión. A cualquier entusiasta del desarrollo de modelos le gustaría aprender también otras formas normales.

Formas comerciales normales

En su libro, Clive Finklestein (Introducción a la ingeniería de la información: de la planificación estratégica a los sistemas de información. Reading, Massachusetts: Addison-Wesley, 1989) adoptó un enfoque diferente de la normalización. Define las formas comerciales normales en términos de coerción a esas formas. Muchos modeladores encuentran este enfoque más intuitivo y más pragmático.

La primera forma normal de negocio (1BNF) saca grupos repetidos a otra entidad. Esta entidad obtiene su propio nombre y atributos de clave primaria (compuesta) de la entidad original y su grupo repetido.

La segunda forma normal comercial (2BNF) elimina los atributos que dependen parcialmente de la clave principal de otra entidad. La clave principal (compuesta) de esta entidad es la clave principal de la entidad en la que se encontraba originalmente, junto con claves adicionales de las que depende completamente el atributo.

La tercera forma normal de negocio (3BNF) toma atributos que son independientes de una clave primaria en otra entidad, donde son completamente dependientes de la clave primaria de esa entidad.

La cuarta forma normal de negocio (4BNF) toma atributos que dependen del valor de la clave primaria o son opcionales para una entidad secundaria, donde dependen completamente del valor de la clave primaria, o donde deben (necesariamente) estar presentes en ese entidad.

La quinta forma normal de negocio (5BNF) aparece como una entidad estructural si existe una dependencia recursiva o de otro tipo entre instancias de una entidad secundaria, o si existe una dependencia recursiva entre instancias de su entidad primaria.

Modelo de datos lógicos completado

El modelo lógico completo debe satisfacer los requisitos del tercer formulario normal comercial e incluir todas las entidades, atributos y relaciones necesarias para respaldar los requisitos de datos y las reglas comerciales asociadas con los datos.

Todas las entidades deben tener nombres que describan su contenido y tener una descripción o definición clara, concisa y completa. Una publicación futura cubrirá un conjunto inicial de pautas para la formación correcta de nombres y descripciones de entidades.

Las relaciones deben incluir una construcción verbal que describa la relación entre entidades, junto con características como pluralidad, necesidad de existencia o posibilidad de ausencia de relación.

NOTA Pluralidad La relación describe el número máximo de instancias de entidad secundaria que se pueden asociar con una instancia de la entidad original.Necesidad de existencia oposibilidad de ausencia La relación se utiliza para determinar el número mínimo de instancias de una entidad secundaria que se puede asociar con una instancia de la entidad original.

Modelo de datos físicos

Una vez que haya creado un modelo lógico completo y adecuado, estará listo para tomar la decisión de elegir una plataforma de implementación. La elección de la plataforma depende de los requisitos para el uso de datos y los principios estratégicos de la configuración de la arquitectura de la corporación. La elección de una plataforma es un tema complejo que va más allá del alcance de este libro.

En ERwin, un modelo físico es una representación gráfica de una base de datos del mundo real. La base de datos física estará formada por tablas, columnas y relaciones. El modelo físico depende de la plataforma elegida para la implementación y los requisitos para usar los datos. El modelo físico de IMS será muy diferente al de Sybase. El modelo físico de los informes OLAP se verá diferente del modelo de OLTP (procesamiento de transacciones en línea).

El modelador de datos y el administrador de la base de datos (DBA) utilizan el modelo lógico, los requisitos de uso y la política de arquitectura corporativa para desarrollar un modelo de datos físicos. Puede desnormalizar el modelo físico para mejorar el rendimiento y crear vistas para admitir los requisitos de uso. Las siguientes secciones detallan el proceso de desnormalización y creación de vistas.

Esta sección proporciona una descripción general del proceso de creación de un modelo físico, recopilación de requisitos de uso de datos, definición de los componentes de un modelo físico y realización de ingeniería inversa. En las siguientes publicaciones, estos temas se tratan con más detalle.

Recopilación de requisitos de uso de datos

Por lo general, recopila los requisitos de uso de datos al principio durante las entrevistas y sesiones de trabajo. Al mismo tiempo, los requisitos deben determinar de la manera más completa posible el uso de los datos por parte del usuario. La actitud superficial y las lagunas en el modelo físico pueden generar costos no planificados y retrasos en la implementación del proyecto. Los requisitos de uso incluyen:

Requisitos de acceso y rendimiento

Características volumétricas (una estimación de la cantidad de datos a almacenar) que permiten al administrador representar el volumen físico de la base de datos.

Estimar la cantidad de usuarios que necesitan acceso simultáneo a los datos para ayudarlo a diseñar su base de datos para niveles de rendimiento aceptables.

Agregados, pivotes y otros datos calculados o derivados que pueden considerarse candidatos para el almacenamiento en estructuras de datos persistentes.

Requisitos para informes y consultas estándar para ayudar al administrador de la base de datos a crear índices.

Vistas (persistentes o virtuales) que ayudarán al usuario a realizar operaciones de agregación o filtrado de datos.

Además del presidente, el secretario y los usuarios, el modelador, el administrador de la base de datos y el arquitecto de la base de datos deben participar en la sesión de requisitos de uso. Deben discutirse los requisitos de datos históricos del usuario. El tiempo que se retienen los datos tiene un impacto significativo en el tamaño de la base de datos. A menudo, los datos más antiguos se almacenan de forma generalizada y los datos atómicos se archivan o eliminan.

Los usuarios deben traer ejemplos de solicitudes e informes a la sesión. Los informes deben estar estrictamente definidos y deben incluir valores atómicos utilizados para cualquier resumen y campos de resumen.

Componentes del modelo de datos físicos

Los componentes de un modelo de datos físicos son tablas, columnas y relaciones. Es probable que las entidades del modelo lógico se conviertan en tablas en el modelo físico. Los atributos booleanos se convierten en columnas. Las relaciones lógicas se convertirán en limitaciones para la integridad de las relaciones. Algunas relaciones lógicas no se pueden implementar en una base de datos física.

Ingeniería inversa

Cuando un modelo lógico no está disponible, es necesario volver a crear el modelo a partir de la base de datos existente. En ERwin, este proceso se denomina ingeniería inversa. La ingeniería inversa se puede realizar de varias formas. El modelador puede explorar las estructuras de datos en la base de datos y recrear tablas en un entorno de modelado visual. Puede importar lenguaje de definiciones de datos (DDL) a una herramienta que admita ingeniería inversa (como Erwin). Las herramientas avanzadas como ERwin incluyen funciones que proporcionan comunicación ODBC con una base de datos existente para crear un modelo leyendo directamente estructuras de datos. La ingeniería inversa con ERwin se discutirá en detalle en una publicación futura.

Usar límites funcionales corporativos

Al construir un modelo lógico para un modelador, es importante asegurarse de que el nuevo modelo sea coherente con el modelo corporativo. Usar límites funcionales corporativos significa modelar datos en términos usados dentro de una corporación. La forma en que se utilizan los datos en una empresa cambia más rápido que los datos en sí. En cada modelo lógico, los datos deben presentarse de manera holística, independientemente del dominio comercial al que dan soporte. Las entidades, atributos y relaciones deben definir las reglas comerciales a nivel de corporación.

NOTA Algunos de mis colegas se refieren a estos límites funcionales corporativos como modelos del mundo real. El modelado del mundo real anima al modelador a ver la información en términos de sus relaciones y relaciones realmente inherentes.

El uso de límites funcionales corporativos para un modelo de datos que se construye adecuadamente proporciona la base para respaldar las necesidades de información de cualquier número de procesos y aplicaciones, lo que permite a la corporación explotar de manera más eficiente uno de sus activos más valiosos: la información.

¿Qué es un modelo de datos empresarial?

Modelo de datos empresariales (EDM) contiene entidades, atributos y relaciones que representan las necesidades de información de una corporación. La EDM generalmente se clasifica de acuerdo con áreas temáticas, que representan grupos de entidades relacionadas con el soporte de necesidades comerciales específicas. Algunas áreas temáticas pueden cubrir funciones comerciales específicas, como la gestión de contratos, mientras que otras pueden incluir entidades que describen productos o servicios.

Cada modelo lógico debe corresponder al dominio existente del modelo de datos corporativos. Si el modelo lógico no cumple con este requisito, se le debe agregar un modelo de dominio. Esta comparación asegura que el modelo corporativo sea mejorado o ajustado y que todos los esfuerzos de modelado lógico estén coordinados dentro de la corporación.

EDM también incluye entidades específicas que definen el alcance de los valores de los atributos clave. Estas entidades no tienen padres y se definen como independientes. Las entidades independientes se utilizan a menudo para mantener la integridad de las relaciones. Estas entidades se identifican con varios nombres diferentes, como tablas de códigos, tablas de referencia, tablas de tipos o tablas de clasificación. Utilizaremos el término "objeto comercial corporativo". Un objeto comercial empresarial es una entidad que contiene un conjunto de valores de atributos que son independientes de cualquier otra entidad. Los objetos comerciales corporativos deben usarse de manera coherente dentro de una corporación.

Construyendo un modelo de datos corporativos aumentando

Hay organizaciones donde el modelo corporativo se ha construido de principio a fin como resultado de un único esfuerzo concertado. Por otro lado, la mayoría de las organizaciones construyen modelos corporativos bastante completos escalando.

Construir significa construir algo secuencialmente, capa por capa, tal como a una ostra le crece una perla. Cada modelo de datos creado proporciona una contribución a la formación del EDM. La construcción de un EDM de esta manera requiere pasos de modelado adicionales para agregar nuevas estructuras de datos y dominios o aumentar las estructuras de datos existentes. Esto hace posible construir un modelo de datos empresarial aumentando, agregando iterativamente niveles de detalle y refinamiento.

Concepto de metodología de modelado

Existen varias metodologías de modelado de datos visuales. ERwin admite dos:

IDEF1X (Definición de integración para modelado de información: descripción integrada de modelos de información).

IE (Ingeniería de la información).

IDEF1X es una buena metodología y el uso de su notación está muy extendido

Descripción integrada de modelos de información

IDEF1X es una metodología de modelado de datos altamente estructurada que amplía la metodología IDEF1 adoptada como estándar FIPS (Estándares federales de procesamiento de información). IDEF1X utiliza un conjunto altamente estructurado de tipos de construcciones de modelado y da como resultado un modelo de datos que requiere una comprensión de la naturaleza física de los datos antes de que dicha información pueda estar disponible.

La estructura rígida de IDEF1X obliga al modelador a asignar características a entidades que pueden no corresponder con las realidades del mundo circundante. Por ejemplo, IDEF1X requiere que todos los subtipos de entidad sean exclusivos. Esto lleva al hecho de que una persona no puede ser a la vez cliente y empleado. Mientras que la práctica real nos dice lo contrario.

Ingeniería de Información

Clive Finklestein es a menudo referido como el padre de la ingeniería de la información, aunque James Martin (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983) compartió conceptos similares con él. La Ingeniería de la Información utiliza un enfoque impulsado por los negocios para la gestión de la información y usa una notación diferente para representar las reglas comerciales. IE sirve como una extensión y desarrollo de la notación y los conceptos centrales de la metodología ER propuesta por Peter Chen.

IE proporciona la infraestructura para respaldar los requisitos de información al integrar la planificación estratégica corporativa con los sistemas de información que se están desarrollando. Esta integración permite que la gestión de los recursos de información esté más alineada con las perspectivas estratégicas a largo plazo de la corporación. Este enfoque impulsado por los negocios ha llevado a muchos modeladores a elegir IE sobre otras metodologías que tienden a enfocarse en desafíos de desarrollo a corto plazo.

IE propone una secuencia de acciones que lleva a una corporación a identificar todas sus necesidades de información para recolectar y administrar datos e identificar relaciones entre objetos de información. Como resultado, los requisitos de información se articulan claramente sobre la base de las directivas de gestión y se pueden traducir directamente en un sistema de información de gestión que respaldará las necesidades de información estratégica.

Conclusión

Comprender cómo utilizar una herramienta de modelado de datos como ERwin es solo una parte del problema. Además, debe comprender cuándo se resuelven las tareas de modelado de datos y cómo se recopilan los requisitos de información y las reglas comerciales que deben representarse en el modelo de datos. La realización de sesiones de trabajo proporciona el entorno más propicio para recopilar requisitos de información en un entorno que incluye expertos en el dominio, usuarios y profesionales de tecnología de la información.

La construcción de un buen modelo de datos requiere analizar e investigar los requisitos de información y las reglas comerciales recopiladas a través de sesiones de trabajo y entrevistas. El modelo de datos resultante debe compararse con el modelo empresarial, si es posible, para garantizar que no entre en conflicto con los modelos de objetos existentes e incluya todos los objetos necesarios.

El modelo de datos consta de modelos lógicos y físicos que representan los requisitos de información y las reglas comerciales. El modelo lógico debe reducirse a la tercera forma normal. La tercera forma normal restringe, agrega, actualiza y elimina anomalías en la estructura de datos para respaldar el principio de "un hecho en un lugar". Los requisitos de información recopilados y las reglas comerciales deben analizarse e investigarse. Deben compararse con el modelo empresarial para garantizar que no entren en conflicto con los modelos de objetos existentes e incluyan todos los objetos necesarios.

En ERwin, el modelo de datos incluye modelos lógicos y físicos. ERwin implementa el enfoque ER y le permite crear objetos de modelo lógicos y físicos para representar los requisitos de información y las reglas comerciales. Los objetos del modelo lógico incluyen entidades, atributos y relaciones. Los objetos del modelo físico incluyen tablas, columnas y restricciones sobre la integridad de las relaciones.

Una de las siguientes publicaciones cubrirá los temas de identificación de entidades, definición de tipos de entidad, elección de nombres y descripciones de entidad, así como algunas técnicas para evitar los errores de modelado más comunes asociados con el uso de entidades.

Las entidades deben tener un conjunto completo de atributos, de modo que cada hecho sobre cada entidad pueda ser representado por sus atributos. Cada atributo debe tener un nombre que refleje su significado, un tipo de datos booleano y una descripción o definición clara, breve y completa. En una futura publicación de blog, veremos un conjunto inicial de pautas para formatear correctamente los nombres y descripciones de los atributos. Las relaciones deben incluir una construcción verbal que describa la relación entre entidades, junto con características como pluralidad, necesidad de existencia o posibilidad de ausencia de relación.

NOTA Pluralidad La relación describe el número máximo de instancias de entidad secundaria que se pueden asociar con una instancia de la entidad original.Necesidad de existencia o posibilidad de ausencia La relación sirve para determinar el número mínimo de instancias de una entidad secundaria que se puede asociar con una instancia del original.

Cada vez más, los profesionales de TI centran su atención en las soluciones de gestión de datos basadas en modelos de datos estándar de la industria y plantillas de decisiones empresariales. Los modelos de datos físicos complejos y los informes de inteligencia empresarial listos para descargar para áreas específicas de actividad le permiten unificar el componente de información de la empresa y acelerar significativamente la ejecución de los procesos empresariales. Las plantillas de soluciones permiten a los proveedores de servicios aprovechar el poder de la información no estándar oculta en los sistemas existentes, reduciendo así los tiempos de ejecución, los costos y los riesgos del proyecto. Por ejemplo, los proyectos del mundo real muestran que el modelo de datos y las plantillas de decisiones comerciales pueden reducir el esfuerzo de desarrollo en un 50%.

Un modelo lógico de la industria es una vista estructurada lógicamente, integrada y específica del dominio de toda la información que debe residir en un almacén de datos empresarial para responder preguntas comerciales tanto estratégicas como tácticas. El propósito principal de los modelos es facilitar la orientación en el espacio de datos y ayudar a resaltar los detalles que son importantes para el desarrollo empresarial. En las condiciones modernas, para un negocio exitoso, es imperativo tener una comprensión clara de los vínculos entre los diversos componentes y tener una buena idea del panorama general de la organización. La identificación de todos los detalles y relaciones mediante modelos permite el uso más eficiente del tiempo y las herramientas para organizar el trabajo de la empresa.

Un ejemplo de un modelo de “SIG para gobiernos y gobiernos locales”.

Hoy en día, es estratégicamente importante que los proveedores de software y servicios puedan responder rápidamente a los cambios en la industria asociados con las innovaciones tecnológicas, la eliminación de las restricciones gubernamentales y la complicación de las cadenas de suministro. Junto con los cambios en el modelo comercial, aumenta la complejidad y el costo de la tecnología de la información necesaria para respaldar las operaciones de una empresa. La gestión de datos es especialmente difícil en un entorno donde los sistemas de información corporativos, así como los requisitos funcionales y comerciales para ellos, cambian constantemente.

Los modelos de datos de la industria están destinados a ayudar a facilitar y optimizar este proceso, al transferir el enfoque de TI al nivel moderno.

Modelos de datos de la industria de la empresaEsri

Los modelos de datos de Esri ArcGIS son plantillas de trabajo para usar en proyectos GIS y para crear estructuras de datos para diferentes áreas de aplicación. La construcción de modelos de datos implica la creación de un diseño conceptual, una estructura lógica y física, que luego se puede utilizar para construir una geodatabase personal o corporativa. ArcGIS proporciona herramientas para crear y administrar un esquema de base de datos, y las plantillas de modelo de datos se utilizan para lanzar rápidamente un proyecto GIS en una variedad de aplicaciones e industrias. Esri ha dedicado una gran cantidad de tiempo a la comunidad de usuarios para desarrollar una variedad de plantillas que pueden proporcionar un comienzo rápido para el diseño de una geodatabase empresarial. Estos proyectos se describen y documentan en support.esri.com/datamodels. A continuación, en el orden en que aparecen en este sitio, hay una traducción semántica de los nombres de los modelos de industria de Esri:

Registro de direcciones
Agricultura
Meteorología
Datos espaciales básicos
La biodiversidad
Espacio interior de edificios
Contabilidad de gases de efecto invernadero
Mantener los límites administrativos
Establecimiento militar. Servicio de inteligencia
Energía (incluido el nuevo protocolo ArcGIS MultiSpeak)
Estructuras ecológicas
Ministerio de Situaciones de Emergencia. Brigada de bomberos
Inventario forestal
Silvicultura
Geología
SIG a nivel nacional (e-gov)
Aguas subterráneas y aguas residuales
Cuidado de la salud
Arqueología y conservación de sitios conmemorativos
seguridad nacional
Hidrología
Organización Hidrográfica Internacional (OHI). Formato S-57 para ENC
Riego
Registro de la Propiedad
Gobierno municipal
Navegación náutica
Catastro estatal
Estructuras de petróleo y gas
Oleoductos
Almacenamiento ráster
Batimetría, relieve del fondo marino
Telecomunicaciones
Transporte
Abastecimiento de agua, alcantarillado, vivienda y servicios comunales

Estos modelos contienen todas las características necesarias del estándar de la industria, a saber:

están disponibles gratuitamente;
no están vinculados a la tecnología del fabricante "elegido";
creado como resultado de la implementación de proyectos reales;
creado con la participación de expertos de la industria;
diseñado para proporcionar interacción de información entre varios productos y tecnologías;
no contradiga otras normas y regulaciones;
utilizado en proyectos terminados en todo el mundo;
están diseñados para trabajar con información durante todo el ciclo de vida del sistema que se está creando, y no el proyecto en sí;
ampliable según las necesidades del cliente sin perder compatibilidad con otros proyectos y / o modelos;
acompañado de materiales y ejemplos adicionales;
utilizado en guías y materiales técnicos de diversas empresas industriales;
una gran comunidad de participantes, mientras que el acceso a la comunidad está abierto a todos;
un gran número de referencias a modelos de datos en publicaciones en los últimos años.

Esri forma parte de un grupo de expertos de organismos independientes que recomiendan varios modelos de la industria, como PODS (Pipeline Open Data Standards, un estándar abierto para la industria del petróleo y el gas; PODS se está implementando actualmente como una geodatabase de Esri PODS Esri Spatial 5.1.1 ) o una geodatabase (geodatabase) de ArcGIS for Aviation, que tiene en cuenta las recomendaciones de la OACI y la FAA, así como el estándar de intercambio de datos de navegación AIXM 5.0. Además, existen modelos recomendados que se adhieren estrictamente a los estándares de la industria existentes, como S-57 y ArcGIS for Maritime (características marinas y costeras), así como modelos creados a partir del trabajo realizado por Esri Professional Services y son estándares de facto en el área correspondiente. Por ejemplo, GIS para el gobierno nacional y local influyó en los estándares de NSDI e INSPIRE, y el uso de Hydro y Groundwater (hidrología y agua subterránea) se usa mucho en la suite profesional ArcHydro y en productos comerciales de libre acceso. Cabe señalar que Esri también admite estándares de facto como NHDI. Todos los modelos de datos propuestos están documentados y listos para su uso en los procesos de TI de la empresa. Los materiales que acompañan a los modelos incluyen:

Diagramas UML de relaciones de entidades;
estructuras de datos, dominios, directorios;
plantillas de geodatabase listas para usar en formato ArcGIS GDB;
datos de muestra y aplicaciones de muestra;
ejemplos de scripts de carga de datos, ejemplos de utilidades de análisis;
libros de referencia sobre la estructura de datos propuesta.

Esri reúne su experiencia en la construcción de modelos de la industria en forma de libros y localiza el material publicado. Esri CIS ha localizado y publicado los siguientes libros:

Arquitectura orientada a servicios geoespaciales (SOA);
Diseño de geodatabases para transporte;
Sistemas corporativos de información geográfica;
GIS: nueva energía para empresas eléctricas y de gas;
Petróleo y gas en un mapa digital;
Modelando nuestro mundo. Guía de diseño de geodatabase de Esri;
Pensando en SIG. Planificación de SIG: un manual para gerentes;
Sistemas de Información Geográfica. Lo esencial;
SIG para la gestión administrativa y económica;
Web GIS. Principios y aplicaciones;
Estrategias de diseño de sistemas, 26ª edición;
68 números de la revista ArcReview con publicaciones de empresas y usuarios de sistemas GIS;
... y muchas otras notas y publicaciones temáticas.

Por ejemplo, el libro " Modelando nuestro mundo ..."(traducción) es una guía completa y una referencia para el modelado de datos SIG en general, y el modelo de datos de geodatabase en particular. El libro muestra cómo llegar a las decisiones correctas de modelado de datos, decisiones que están involucradas en todos los aspectos de un proyecto GIS, desde el diseño de la base de datos hasta la recolección de datos y el análisis espacial y la visualización Describe en detalle cómo diseñar una base de datos geográfica apropiada para el proyecto, configurar la funcionalidad de la base de datos sin programación, administrar el flujo de trabajo en proyectos complejos, modelar varias estructuras de red como fluviales, de transporte o eléctricas redes, integrar imágenes de satélite en el proceso de análisis y visualización geográficos, y crear modelos 3D de datos GIS. Libro " Diseño de geodatabases para transporte"contiene enfoques metodológicos que han sido probados en un gran número de proyectos y cumplen plenamente con los requisitos legislativos de Europa y Estados Unidos, así como con los estándares internacionales. Y en el libro" GIS: nueva energía para plantas eléctricas y de gas"Utilizando ejemplos del mundo real, muestra los beneficios que los SIG corporativos pueden aportar al proveedor de energía, incluidos aspectos como el servicio al cliente, las operaciones de red y otros procesos comerciales.

Algunos de los libros, traducidos y originales, publicados en ruso por Esri CIS y DATA +. Abordan tanto cuestiones conceptuales relacionadas con la tecnología GIS como muchos aspectos aplicados del modelado y la implementación de GIS de varios tamaños y propósitos.

Consideraremos la aplicación de modelos industriales utilizando el ejemplo del BISDM (Building Interior Space Data Model, modelo de información del espacio interno de un edificio) versión 3.0. BISDM es un desarrollo de un modelo BIM (Building Information Model) más general y está destinado a ser utilizado en el diseño, construcción, operación y desmantelamiento de edificios y estructuras. Utilizado en el software GIS, le permite intercambiar geodatos de manera eficiente con otras plataformas e interactuar con ellas. Se refiere al grupo general de tareas de gestión financiera (gestión de la infraestructura de la organización). Enumeremos las principales ventajas del modelo BISDM, cuyo uso permite:

organizar el intercambio de información en un entorno heterogéneo de acuerdo con reglas uniformes;
obtener una encarnación "física" del concepto BIM y las reglas recomendadas para la gestión de proyectos de construcción;
mantener mediante GIS un repositorio único durante todo el ciclo de vida de un edificio (desde el diseño hasta el desmantelamiento);
coordinar el trabajo de varios especialistas en el proyecto;
visualizar el cronograma planificado y las etapas de construcción para todos los participantes;
dar una estimación preliminar del costo y el tiempo de construcción (datos 4D y 5D);
monitorear el progreso del proyecto;
garantizar un funcionamiento de alta calidad del edificio, incluido el mantenimiento y las reparaciones;
formar parte del sistema de gestión de activos, incluidas las funciones de análisis de la eficiencia del uso del espacio (arrendamiento, almacén, gestión de empleados);
calcular y gestionar los objetivos de eficiencia energética del edificio;
Simular el movimiento de los flujos humanos.

BISDM define las reglas para trabajar con datos espaciales a nivel de las instalaciones internas de un edificio, incluido el propósito y los tipos de uso, las comunicaciones instaladas, los equipos instalados, la contabilidad de las reparaciones y el mantenimiento, los incidentes de registro y las relaciones con otros activos de la empresa. El modelo ayuda a crear un repositorio unificado de datos geográficos y no geográficos. La experiencia de las empresas líderes en el mundo se utilizó para aislar entidades y modelar a nivel de geodatabase (geodatabase) de las relaciones espaciales y lógicas de todos los elementos físicos que forman tanto el edificio en sí como sus instalaciones internas. Seguir los principios de BISDM puede simplificar significativamente las tareas de integración con otros sistemas. La primera etapa suele ser la integración CAD. Luego, durante la operación del edificio, se utiliza el intercambio de datos con sistemas ERP y EAM (SAP, TRIRIGA, Maximo, etc.).

Visualización de elementos estructurales BISDM usando ArcGIS.

En el caso de utilizar BISDM, el cliente / propietario de la instalación recibe un intercambio de información de punta a punta desde la idea de crear un objeto hasta el desarrollo de un proyecto completo, control de la construcción con obtención de información relevante por parte del tiempo de puesta en funcionamiento de la instalación, control de los parámetros durante la operación e incluso durante la reconstrucción o el desmantelamiento de la instalación. Siguiendo el paradigma BISDM, el SIG y la base de datos geográfica creada con su ayuda se convierte en un repositorio de datos común para los sistemas relacionados. A menudo, el GDB contiene datos creados y operados por sistemas de terceros. Esto debe tenerse en cuenta al diseñar la arquitectura del sistema que se está creando.

En una determinada etapa, la "masa crítica" acumulada de información le permite pasar a un nuevo nivel de calidad. Por ejemplo, una vez finalizada la fase de diseño de un nuevo edificio, es posible visualizar automáticamente modelos de levantamientos 3D en GIS, compilar una lista de equipos instalados, calcular el kilometraje de los servicios públicos que se instalarán, realizar una serie de comprobaciones e incluso dar una estimación financiera preliminar del costo del proyecto.

Una vez más, observamos que cuando BISDM y ArcGIS se usan juntos, es posible construir automáticamente modelos 3D a partir de los datos acumulados, ya que la geodatabase contiene una descripción completa del objeto, incluidas las coordenadas z, la pertenencia al piso y los tipos de conexiones de elementos. , métodos de instalación de equipos, material, recorridos disponibles, movimiento de personal, finalidad funcional de cada elemento, etc. etc. Cabe señalar que después de la importación inicial de todos los materiales de diseño en el BISDM GDB, existe la necesidad de contenido de información adicional para:

colocación de modelos 3D de objetos y equipos en lugares designados;
recopilar información sobre el costo de los materiales y el procedimiento para su colocación e instalación;
control de la permeabilidad según las dimensiones del equipo no estándar instalado.

Debido al uso de ArcGIS, es más fácil importar referencias y objetos 3D adicionales de fuentes externas, porque La interoperabilidad de datos de ArcGIS le permite crear procedimientos para importar dichos datos y colocarlos correctamente dentro del modelo. Todos los formatos utilizados en la industria son compatibles, incluidos IFC, AutoCAD Revit, Bentlye Microstation.

Modelos de datos industriales de IBM

IBM proporciona un conjunto de herramientas y modelos de gestión de almacenamiento para una variedad de áreas comerciales:

Almacén de datos bancarios y de mercados financieros de IBM (finanzas)
Almacén de datos bancarios de IBM
Modelos de servicios y procesos bancarios de IBM
Modelo de datos del plan de salud de IBM (atención médica)
IBM Insurance Information Warehouse (seguros)
Modelos de servicios y procesos de seguros de IBM
IBM Retail Data Warehouse (minorista)
Almacén de datos de telecomunicaciones de IBM (telecomunicaciones)
Paquete de almacén de InfoSphere:
- para Customer Insight (para comprender a los clientes)
- para Market and Campaign Insight (para comprender la empresa y el mercado)
- para Supply Chain Insight (para comprender a los proveedores).

Por ejemplo, el modelo IBMBancarioyFinancieroMercadosDatosDepósito está diseñado para abordar los problemas específicos de la industria bancaria en términos de datos, y IBMBancarioProcesoyServicioModelos- en términos de procesos y SOA (Arquitectura Orientada a Servicios). Para la industria de las telecomunicaciones, se presentan modelos IBMInformaciónEstructura (IFW) y IBMTelecomunicacionesDatosDepósito (TDW)... Ayudan a acelerar significativamente el proceso de creación de sistemas analíticos, así como a reducir los riesgos asociados con el desarrollo de aplicaciones de inteligencia empresarial, gestión de datos corporativos y organización de almacenes de datos, teniendo en cuenta las particularidades de la industria de las telecomunicaciones. Las capacidades de IBM TDW cubren todo el espectro del mercado de las telecomunicaciones, desde proveedores de Internet y operadores de redes de cable que ofrecen servicios de telefonía alámbrica e inalámbrica, transmisión de datos y contenido multimedia, hasta empresas multinacionales que brindan servicios de comunicación telefónica, satelital, de larga distancia e internacionales, como así como redes globales de organizaciones. Hoy en día, TDW es utilizado por grandes y pequeños proveedores de servicios inalámbricos y por cable en todo el mundo.

Una herramienta llamada InfoSphere Warehouse Pack para Customer Insight proporciona contenido empresarial estructurado y fácilmente implementable para un número creciente de proyectos e industrias empresariales, que incluyen banca, seguros, finanzas, seguros médicos, telecomunicaciones, venta minorista y distribución. Para usuarios empresariales InfoSphere Warehouse Pack para Market y Campaign Insight ayuda a maximizar la eficiencia de las actividades de análisis de mercado y las campañas de marketing a través de un proceso paso a paso de desarrollo y teniendo en cuenta las características específicas del negocio. Mediante el uso InfoSphere Warehouse Pack para Supply Chain Insight las organizaciones tienen la capacidad de recibir información actualizada sobre las operaciones de la cadena de suministro.

Posición de Esri dentro de la arquitectura de la solución de IBM.

Particularmente digno de mención es el enfoque de IBM para los servicios públicos y los servicios públicos. Para satisfacer las crecientes demandas de los consumidores, las empresas de servicios públicos necesitan una arquitectura más flexible que las que se utilizan en la actualidad, así como un modelo de objetos estándar de la industria para facilitar el libre flujo de información. Esto aumentará las capacidades de comunicación de las empresas de servicios públicos al permitir una interoperabilidad más rentable y proporcionará a los nuevos sistemas una mejor visibilidad de todos los recursos necesarios, sin importar dónde se encuentren dentro de la organización. La base de este enfoque es SOA (Arquitectura Orientada a Servicios), un modelo de componentes que mapea las funciones de los departamentos y servicios de varias aplicaciones que se pueden reutilizar. Los "servicios" de dichos componentes intercambian datos a través de interfaces sin ataduras rígidas, ocultando al usuario toda la complejidad de los sistemas detrás de ellos. En este modo, las empresas pueden agregar fácilmente nuevas aplicaciones independientemente del proveedor de software, el sistema operativo, el lenguaje de programación u otras características intrínsecas del software. Basado en SOA, el concepto se está implementando A SALVO ( Arquitectura de soluciones para la energía), permite a la empresa de servicios públicos obtener una visión holística y basada en estándares de su infraestructura.

Esri ArcGIS® es una plataforma de software para sistemas de información geográfica (GIS) reconocida a nivel mundial, que proporciona la creación y gestión de activos digitales de redes de energía eléctrica, transmisión, distribución y telecomunicaciones de gas. ArcGIS permite realizar el inventario más completo de los componentes de la red de distribución eléctrica, teniendo en cuenta su ubicación espacial. ArcGIS amplía drásticamente la arquitectura IBM SAFE al proporcionar las herramientas, aplicaciones, flujos de trabajo, análisis y capacidades de integración de información necesarias para administrar una empresa de energía inteligente. ArcGIS dentro del marco de IBM SAFE le permite recibir información de diversas fuentes sobre instalaciones de infraestructura, activos, clientes y empleados con datos precisos sobre su ubicación, así como crear, almacenar y procesar información georreferenciada sobre activos empresariales (soportes, tuberías, cables , transformadores, conductos de cables, etc.). ArcGIS dentro de la infraestructura SAFE conecta dinámicamente las aplicaciones comerciales centrales combinando datos de GIS, SCADA y sistemas de servicio al cliente con información externa, como la intensidad del tráfico, las condiciones climáticas o las imágenes satelitales. Las empresas de servicios públicos utilizan esta información combinada para una variedad de propósitos, desde S.O.R. (la imagen general del entorno operativo) a la inspección del sitio, el mantenimiento, el análisis y la planificación de la red.

Los componentes de información de una empresa de servicios públicos se pueden modelar utilizando varios niveles que van desde el nivel más bajo, físico, hasta el más alto y complejo de lógica empresarial. Estas capas se pueden integrar para cumplir con los requisitos típicos de la industria, como el registro de mediciones automatizado y la gestión de control de supervisión y adquisición de datos (SCADA). Al construir la arquitectura SAFE, las empresas de servicios públicos están logrando avances significativos en la promoción de un modelo de objetos abiertos en toda la industria llamado Modelo de información común (CIM) para energía y servicios públicos. Este modelo proporciona el marco necesario para mover muchas empresas hacia una arquitectura orientada a servicios, ya que fomenta el uso de estándares abiertos para estructurar datos y objetos. Debido al hecho de que todos los sistemas utilizan los mismos objetos, la confusión y la inelasticidad asociadas con diferentes implementaciones de los mismos objetos se reducirán al mínimo. Por lo tanto, la definición del objeto cliente y otros objetos comerciales importantes se unificarán en todos los sistemas de la empresa de suministro de energía. Ahora, con CIM, los proveedores de servicios y los consumidores de servicios pueden compartir una estructura de datos común, lo que facilita la subcontratación de componentes comerciales de alto valor, ya que CIM establece una base común sobre la cual construir el intercambio de información.

Conclusión

Los modelos integrales de datos de la industria brindan a las empresas una vista única e integrada de la información comercial. A muchas empresas les resulta difícil integrar sus datos, aunque este es un requisito previo para la mayoría de los proyectos empresariales. Según un estudio realizado por The Data Warehousing Institute (TDWI), más del 69% de las organizaciones encuestadas encontraron que la integración es una barrera importante para la adopción de nuevas aplicaciones. Por el contrario, la implementación de la integración de datos aporta a la empresa ingresos tangibles y una mayor eficiencia.

Un modelo bien construido identifica de forma única el significado de los datos, que en este caso son datos estructurados (a diferencia de los datos no estructurados, como una imagen, archivo binario o texto, donde el significado puede ser ambiguo). Los más efectivos son los modelos de la industria ofrecidos por proveedores profesionales como Esri e IBM. El alto rendimiento del uso de sus modelos se logra debido al significativo nivel de detalle y precisión. Por lo general, contienen muchos atributos de datos. Además, tanto Esri como IBM tienen una amplia experiencia en modelado y están bien versados en la creación de modelos específicos de la industria.

Arquitectura de base de datos

El esquema KMD es una descripción de la estructura del modelo de datos desde el punto de vista del administrador.

Un esquema AMD es una descripción de un modelo interno o físico. Aquí es donde se almacena la descripción de la ubicación física de los datos en los medios. El esquema almacena indicaciones directas de la ubicación de los datos en la memoria (volúmenes, discos).

El esquema KMD describe la estructura de datos, registros y campos.

Todos los DBMS admiten tres tipos principales de modelos de datos:

1. Modelo jerárquico. Asume algún tipo de entrada de root. Las ramas provienen de las raíces.

No todos los objetos se describen convenientemente de esta manera. No hay enlaces en la jerarquía y es característica una gran redundancia de información.

2. Modelo de red. Le permite mostrar correctamente todas las complejidades de las relaciones.

El modelo es conveniente para representar enlaces con datos del entorno externo, pero menos conveniente para describir en una base de datos, lo que conlleva un trabajo adicional para que el usuario estudie la navegación a través de los enlaces.

3. El modelo relacional. Se basa en el término matemático Relación, una relación, y simplemente, una tabla. Por ejemplo, rectangular bidimensional.

La estructura de datos relacionales fue desarrollada a fines de la década de 1960 por varios investigadores, de los cuales la contribución más significativa fue realizada por el empleado de IBM, Edgar Codd. Con el enfoque relacional, los datos se presentan en forma de tablas bidimensionales, las más naturales para los humanos. Al mismo tiempo, para el procesamiento de datos, Codd sugirió utilizar el aparato de la teoría de conjuntos: unión, intersección, diferencia, producto cartesiano.

Tipo de datos- este concepto tiene el mismo significado que en los lenguajes de programación (es decir, el tipo de datos determina la representación interna en la memoria de la computadora y la forma de almacenar la instancia de datos, así como el conjunto de valores que la instancia de datos puede take y el conjunto de operaciones de datos válidas). Todas las bases de datos modernas existentes admiten tipos de datos especiales diseñados para almacenar datos de tipo entero, punto flotante fraccionario, caracteres y cadenas, fechas del calendario. Muchos servidores de bases de datos tienen implementados otros tipos, por ejemplo, el servidor Interbase tiene un tipo de datos especial para almacenar grandes conjuntos de información binaria (BLOB).

Dominio Es un conjunto potencial de valores de un tipo de datos simple, se parece a un subtipo de datos en algunos lenguajes de programación. Un dominio está definido por dos elementos: un tipo de datos y una expresión booleana que se aplica a los datos. Si esta expresión se evalúa como verdadera, entonces la instancia de datos pertenece al dominio.

Actitud Es una tabla bidimensional de un tipo especial, que consta de un encabezado y un cuerpo.

Bóveda Es un conjunto fijo de atributos, cada uno de los cuales se define en algún dominio, y existe una correspondencia uno a uno entre los atributos y los dominios que los definen.

Cada uno de los atributos se define en su propio dominio. El dominio es el tipo de datos entero y la condición booleana es n> 0. El título no cambia con el tiempo, en contraste con el cuerpo de la relación. Cuerpo de parentesco Es una colección tuplas, cada uno de los cuales es un par atributo-valor.

El poder de la relación es el número de sus tuplas, y grado de actitud- el número de atributos.

El grado de la relación es constante para una relación determinada, mientras que la potencia de la relación cambia con el tiempo. El poder de la relación también se llama número cardinal.

Los conceptos anteriores son teóricos y se utilizan en el desarrollo de herramientas de lenguaje y sistemas de software de DBMS relacional. En el trabajo diario, sus equivalentes informales se utilizan en cambio:

actitud - mesa;

atributo - columna o campo;

tupla - registro o cadena.

Por lo tanto, el grado de la razón es el número de columnas en la tabla y el número cardinal es el número de filas.

Dado que una relación es un conjunto, y en la teoría de conjuntos clásica, por definición, un conjunto no puede contener elementos coincidentes, una relación no puede tener dos tuplas idénticas. Por lo tanto, para una relación determinada, siempre hay un conjunto de atributos que identifican de forma única una tupla. Este conjunto de atributos se llama llave.

La clave debe cumplir los siguientes requisitos:

· Debe ser único;

· Debe ser mínimo, es decir, eliminar cualquier atributo de la clave conduce a una violación de la unicidad.

Como regla general, el número de atributos en la clave es menor que el grado de relación, sin embargo, como último recurso, la clave puede contener todos los atributos, ya que la combinación de todos los atributos satisface la condición de unicidad. Normalmente, una relación tiene varias claves. De todas las claves de la relación (también se denominan "claves posibles"), se elige una como Clave primaria... Al elegir Clave primaria Por lo general, se prefiere la clave con la menor cantidad de atributos. Tampoco es práctico utilizar claves con valores de cadena largos.

En la práctica, un atributo numérico especial, un cero autoincremental, se usa a menudo como clave primaria, cuyo valor puede ser generado por un disparador (un disparador es un procedimiento especial llamado cuando se realizan cambios en la base de datos) o por medios especiales definidos en el motor DBMS.

Los conceptos básicos descritos en este capítulo no son específicos de ninguna implementación de base de datos en particular, pero son comunes a todas ellas. Por tanto, estos conceptos son la base de un determinado modelo general, que se denomina modelo de datos relacionales.

El fundador del enfoque relacional, Date, estableció que el modelo relacional tiene tres partes:

· Estructural;

· Manipulante;

· Holístico.

En la parte estructural del modelo, las relaciones se fijan como la única estructura de datos utilizada en el modelo relacional.

En la parte de manipulación, dos mecanismos básicos para manipular las bases relacionales son fijos: el álgebra relacional y el cálculo relacional.

Se entiende por parte integral un cierto mecanismo para asegurar la no destructibilidad de los datos. La parte integral abarca dos requisitos básicos para la integridad de las bases de datos relacionales: integridad de la entidad e integridad referencial.

Requisito integridad de la entidad es que cualquier tupla de cualquier relación debe ser distinguible de cualquier otra tupla de esta relación, es decir, en otras palabras, cualquier relación debe tener una clave primaria. Este requisito debe cumplirse si se cumplen las propiedades básicas de la relación.

En el lenguaje de manipulación de datos, así como en el lenguaje de consulta, se ejecuta un aparato matemático llamado álgebra de relaciones, para lo cual se definen las siguientes acciones:

1. Operaciones estándar: - intersección, - unión, \ - diferencia, X - producto cartesiano.

2. Específico: proyección, limitación, conexión, división.

una. Unión.

ShD SHM EI NR

R 1 (número de pieza, número de material, unidad de medida, tasa de consumo)

R 2 (ШД, ШМ, ЕИ, НР)

Necesito encontrar

Se supone la unión de los conjuntos R 1 y R 2. En esta operación, el grado se conserva y la cardinalidad del conjunto de resultados

B. Intersección.

Resalte las líneas coincidentes.

C. Diferencia.

Eliminando tuplas de R 1 que coinciden con R 2.

D. Producto cartesiano.

Aquí es donde se concatenan las tuplas.

Cada línea de un conjunto se concatena con cada línea del otro.

Se dan dos conjuntos:

El producto cartesiano es el siguiente:

En este caso, el grado S es igual a, y, es decir obtienes 12 filas y 5 columnas.

La base de datos corporativa es el enlace central del sistema de información corporativa y le permite crear un espacio de información único para la corporación. Bases de datos corporativas

Comparte tu trabajo en las redes sociales

Si este trabajo no le conviene en la parte inferior de la página, hay una lista de trabajos similares. También puede utilizar el botón de búsqueda

TEMA V. BASES DE DATOS CORPORATIVAS

V .1. Organización de datos en sistemas corporativos. Bases de datos corporativas.

V .2. DBMS y soluciones estructurales en sistemas corporativos.

V .3. Tecnologías de Internet / Intranet y soluciones corporativas para el acceso a bases de datos.

V .1. ORGANIZACIÓN DE DATOS EN SISTEMAS CORPORATIVOS. BASES DE DATOS CORPORATIVAS

Existen varias definiciones de bases de datos.

El término base de datos se puede resumir como una colección de datos relacionados lógicamente destinados a ser compartidos.

Requisitos básicos para bases de datos:

Completitud de la presentación de datos. Los datos de la base de datos deben representar adecuadamente toda la información sobre el objeto y deben ser suficientes para SAO.
Integridad de la base de datos. Los datos deben ser guardados al momento de procesar sus ODS y en cualquier situación que surja durante el trabajo.
Flexibilidad de la estructura de datos. La base de datos debe permitir cambiar las estructuras de datos sin violar su integridad y exhaustividad cuando cambian las condiciones externas.
Factibilidad. Esto significa que debe haber una representación objetiva de varios objetos, sus propiedades y relaciones.
Disponibilidad. Es necesario proporcionar delimitación del acceso a los datos.
Redundancia. La base de datos debe tener una redundancia mínima en la representación de datos sobre cualquier objeto.

Conocimiento significa un conjunto de hechos, patrones y reglas heurísticas que se pueden usar para resolver el problema.

Distinguir diferentes formas de presentar los datos.

Datos físicos - son datos almacenados en la memoria de la computadora.

Arroz. 1.1. La estructura de la interacción de los departamentos con los recursos de información de la corporación.

Las bases de datos corporativas son enfocado (centralizado) y distribuido.

Figura 1.2. Esquema heterogéneo base de datos centralizada

Gran flujo de intercambio de datos;
Alto tráfico en la red;
Baja confiabilidad;
Rendimiento general deficiente.

Mayor grado de simultaneidad de procesamiento debido al equilibrio de carga;
Mejorar el uso de datos en el campo al realizar consultas remotas (remotas);
Costos mas bajos;
Facilidad para administrar bases de datos locales.

Figura 1.3. Base de datos de corporaciones distribuida.

Démosle la siguiente definición de una base de datos distribuida.

Los requisitos de rendimiento más importantes para una base de datos distribuida son:

Escalabilidad;
Compatibilidad;
Soporte para varios modelos de datos;
Portabilidad;
Transparencia de ubicación;
Autonomía de los nodos de una base de datos distribuida (Site Autonomy);
Procesamiento de solicitudes distribuido;
Ejecución de transacciones distribuidas.
Soporte para un sistema de seguridad homogéneo.

La principal tarea de una base de datos distribuida - distribución de datos a través de la red y acceso a ellos. Existen las siguientes formas de resolver este problema:

Cada nodo almacena y usa su propio conjunto de datos que está disponible para consultas remotas. Esta distribución está dividida.
Algunos datos que se utilizan con frecuencia en sitios remotos pueden estar duplicados. Esta distribución se llama parcialmente duplicada.
Todos los datos se duplican en cada nodo. Esta distribución se llama completamente duplicada.
Algunos archivos se pueden dividir horizontalmente (se selecciona un subconjunto de registros) o verticalmente (se selecciona un subconjunto de campos de atributos), mientras que los subconjuntos seleccionados se almacenan en diferentes nodos junto con datos sin dividir. Esta distribución se llama dividida (fragmentada).

Al crear una base de datos distribuida, a nivel conceptual, debes resolver las siguientes tareas:

Es necesario tener un diagrama conceptual único de toda la red. Esto proporcionará una transparencia lógica de los datos para el usuario, como resultado de lo cual podrá realizar una solicitud a toda la base de datos, estando detrás de un terminal separado (parece funcionar con una base de datos centralizada).
Se necesita un esquema para ubicar los datos en la red. Esto proporcionará transparencia en la ubicación de los datos, gracias a lo cual el usuario no tiene que especificar dónde enviar la solicitud para obtener los datos requeridos.
Es necesario solucionar el problema de la heterogeneidad de las bases de datos distribuidas. Las bases de datos distribuidas pueden ser homogéneas o heterogéneas en términos de hardware y software. El problema de la heterogeneidad es relativamente fácil de resolver si la base de datos distribuida es heterogénea en el sentido de hardware, pero homogénea en el sentido de software (el mismo DBMS en los nodos). Si se utilizan diferentes DBMS en los nodos de un sistema distribuido, se requieren medios para transformar las estructuras de datos y los lenguajes. Esto debería proporcionar una transformación transparente a través de los nodos de la base de datos distribuida.
Es necesario solucionar el problema de la gestión del diccionario. Para proporcionar todo tipo de transparencia en una base de datos distribuida, necesita programas que gestionen numerosos diccionarios y libros de referencia.
Necesita definir métodos para ejecutar consultas en una base de datos distribuida. Los métodos para ejecutar consultas en una base de datos distribuida difieren de los de bases de datos centralizadas, ya que las partes individuales de las consultas deben ejecutarse en la ubicación de los datos relevantes y los resultados parciales deben pasarse a otros nodos; al mismo tiempo, debe garantizarse la coordinación de todos los procesos.
Es necesario solucionar el problema de la ejecución de consultas en paralelo. Una base de datos distribuida requiere un sofisticado mecanismo de control de concurrencia, que, en particular, debe asegurar la sincronización cuando se actualiza la información, lo que asegura la consistencia de los datos.
Se requiere una metodología desarrollada para la distribución y ubicación de datos, incluida la división, que es uno de los principales requisitos para una base de datos distribuida.

aumentar el salario de todos los empleados de la empresa;
calcular el interés bancario en las cuentas de todos los clientes;
realizar cambios en la lista de todos los productos en stock;
encontrar el resumen requerido de todos los textos almacenados en la biblioteca o en el sistema de recuperación de información bibliográfica;
encontrar una descripción del contrato requerido en un archivo que contenga documentos legales;
revise todos los archivos que contienen descripciones de patentes y busque una patente (si la hubiera) similar a la propuesta nuevamente.

Un banco de datos puede estar presente en la estructura de una corporación.

Base de datos se considera un sistema de información y referencia, cuya finalidad principal es:

en la acumulación y mantenimiento en funcionamiento de un conjunto de información que constituye la base de información de todo el sistema automatizado o de un determinado conjunto de tareas resueltas en él;
en la emisión de los datos requeridos por la tarea o usuario;
al proporcionar acceso colectivo a información almacenada;
en asegurar la gestión necesaria del uso de la información contenida en la base de información.

V .2. DBMS Y SOLUCIONES ESTRUCTURALES EN SISTEMAS CORPORATIVOS

Sistemas de gestión de bases de datos y conocimientos

Un componente importante de los sistemas de información modernos son los sistemas de gestión de bases de datos (DBMS).

DBMS - un conjunto de software y herramientas lingüísticas destinadas a la creación, mantenimiento y uso de bases de datos.

La característica principal del DBMS moderno es que el DBMS moderno admite tecnologías como:

Tecnología cliente / servidor.
Soporte de idiomas de base de datos. esolenguaje de definición de esquema DB (SDL - Lenguaje de definición de esquemas),lenguaje de manipulación de datos (DML), lenguajes integrados SQL (lenguaje de cola estructurado), QDB (consulta por ejemplo) y QMF (función de gestión de consultas ) Es una herramienta de generación de informes y especificación de consultas periféricas DB 2, etc.;
Gestión directa de datos en memoria externa.
Gestión de búferes RAM.
Gestión de transacciones. OLTP - tecnología (Procesamiento de transacciones en línea), OLAP - tecnología (Procesamiento de análisis en línea) para DW.
Garantice la protección e integridad de los datos. El uso del sistema está permitido solo a los usuarios que tienen derecho a acceder a los datos. Cuando los usuarios realizan operaciones con datos, se mantiene la coherencia de los datos almacenados (integridad). Esto es importante en los sistemas de información corporativos multiusuario.
Periodización.

El DBMS moderno debe garantizar el cumplimiento de los requisitos de la base de datos enumerados anteriormente. Además, deberán cumplir con los siguientes principios:

Independencia de datos.
Versatilidad. El DBMS debe tener un potente soporte de modelo de datos conceptual para mostrar vistas lógicas personalizadas.
Compatibilidad. El DBMS debe permanecer operativo con el desarrollo de software y hardware.
Redundancia de datos. A diferencia de los sistemas de archivos, una base de datos debe ser una colección única de datos integrados.
Protección de Datos. El DBMS debe brindar protección contra el acceso no autorizado.
Integridad de los datos. El DBMS debe evitar que los usuarios rompan la base de datos.
Gestión de trabajo simultáneo. El DBMS debe proteger la base de datos de inconsistencias en el modo de acceso compartido. Para garantizar un estado coherente de la base de datos, todas las solicitudes (transacciones) de los usuarios deben ejecutarse en un orden específico.
El DBMS debe ser universal. Debe admitir diferentes modelos de datos sobre una única base lógica y física.
El DBMS debe admitir bases de datos centralizadas y distribuidas y, por lo tanto, convertirse en un vínculo importante en las redes informáticas.

sus capacidades en relación con bases de datos distribuidas (corporativas);
su relación con el tipo de modelo de datos implementado en el DBMS.

En relación con las bases de datos corporativas (distribuidas), los siguientes tipos de DBMS se pueden distinguir convencionalmente:

DBMS de "escritorio". Estos productos se centran principalmente en trabajar con datos personales (datos de "escritorio"). Tienen conjuntos de comandos para compartir bases de datos comunes, pero de tamaño pequeño (como una oficina pequeña). En primer lugar, es un DBMS como Assess, dBASE, Paradox, EohPgo. Por qué Assess, dBASE, Paradox, EohPgo tienen un acceso deficiente a los datos corporativos. El caso es que no existe una manera fácil de superar la barrera entre los datos personales y corporativos. Y el caso no es ni siquiera que el mecanismo del DBMS de datos personales (o pequeña oficina) se centre en acceder a los datos a través de muchas pasarelas, productos de interconexión, etc. El problema es que estos mecanismos suelen estar asociados con transferencias de archivos completas y la falta de compatibilidad con índices bifurcados, lo que hace que las colas de servidor prácticamente se atasquen en sistemas grandes.
DBMS multiusuario de alto rendimiento especializado. Dichos DBMS se caracterizan por la presencia de un núcleo de sistema multiusuario, un lenguaje de manipulación de datos y las siguientes funciones típicas de los DBMS multiusuario desarrollados:
organización del grupo de amortiguadores;
la presencia de un sistema para procesar colas de transacciones;
la presencia de mecanismos para el bloqueo de datos multiusuario;
registro de transacciones;
la disponibilidad de mecanismos de control de acceso.

Estos son DBMS como Oracle, DB2, SQL / Server, Informix, Sybase, ADABAS, Titanium y otros brindan un amplio servicio para el procesamiento de bases de datos corporativas.

Cuando se trabaja con bases de datos, se utiliza el mecanismo de transacción.

Transacción Es una unidad lógica de trabajo.

Transacción es una secuencia de declaraciones de manipulación de datos ejecutadascomo un todo(todo o nada) y traduciendo la base de datosde un estado holístico a otro estado holístico.

Una transacción tiene cuatro propiedades importantes conocidas como propiedades ASID:

(A) Atomicidad ... Una transacción se ejecuta como una operación atómica: se ejecuta toda la transacción o no se ejecuta por completo.
(C) Coherencia... Una transacción mueve una base de datos de un estado consistente (consistente) a otro estado consistente (consistente). Dentro de una transacción, se puede violar la coherencia de la base de datos.
(I) Aislamiento ... Las transacciones de diferentes usuarios no deben interferir entre sí (por ejemplo, como si se ejecutaran estrictamente por turno).
(E) Durabilidad... Si la transacción se completa, los resultados de su trabajo deben guardarse en la base de datos, incluso si en el siguiente momento el sistema falla.

La transacción generalmente comienza automáticamente desde el momento en que el usuario se conecta al DBMS y continúa hasta que ocurre uno de los siguientes eventos:

Se emite el comando COMMIT WORK.
Se emitió el comando ROLLBACK WORK.
El usuario se ha desconectado del DBMS.
Hubo una falla del sistema.

Arquitectura cliente / servidor

		Base de datos
Computadora servidor
La red
PC compatible con IBM	PC compatible con IBM	PC compatible con IBM
		Aplicaciones

Arroz. 2.1. Sistema de arquitectura cliente-servidor

La función principal de la computadora cliente es ejecutar la aplicación (interfaz de usuario y lógica de presentación) y comunicarse con el servidor cuando la aplicación lo requiera.

Servidor Es un objeto (computadora) que brinda servicios a otros objetos a pedido de éstos.

Computación distribuída

El término "computación distribuida" se usa a menudo para referirse a dos conceptos diferentes, aunque complementarios:

Base de datos distribuida;
Procesamiento de datos distribuidos.

La aplicación de estos conceptos permite organizar el acceso a la información almacenada en múltiples máquinas para los usuarios finales utilizando diferentes medios.

Hay muchos tipos de servidores:

Servidor de base de datos;
Servidor de impresión;
Servidor de acceso remoto;
Servidor de fax;
Servidor web, etc.

En el corazón de la tecnología subyacente se encuentra Cliente / Servidor son tecnologías tan básicas como:

Tecnologías de sistemas operativos, el concepto de interacción de sistemas abiertos, la creación de entornos orientados a objetos para el funcionamiento de programas;
Tecnologías de telecomunicaciones;
Tecnologías de red;
Tecnologías de interfaz gráfica de usuario ( GUI);
Etc.

Ventajas de la tecnología cliente-servidor:

La tecnología cliente / servidor permite la informática en entornos informáticos heterogéneos. Independencia de plataforma: acceso a entornos de red heterogéneos que incluyen diferentes tipos de computadoras con diferentes sistemas operativos.
Independencia de las fuentes de datos: acceso a la información de bases de datos heterogéneas. Ejemplos de tales sistemas son DB2, SQL / DS, Oracle, Sybase.
Equilibrio de carga entre cliente y servidor.
Realice cálculos donde sea más eficiente;
Proporcionar la capacidad de escalar de manera eficiente;
Computación multiplataforma... La informática multiplataforma se define simplemente como la implementación de tecnologías en entornos informáticos heterogéneos. Aquí se deben proporcionar las siguientes posibilidades:
La aplicación debe ejecutarse en múltiples plataformas;
En todas las plataformas, debe tener la misma interfaz y lógica de trabajo;
La aplicación debe integrarse con el entorno operativo nativo;
Debería comportarse igual en todas las plataformas;
Se le debe proporcionar un soporte simple y consistente.

 Computación distribuída. La computación distribuida implica la distribución del trabajo entre varias computadoras (aunque la computación distribuida es un concepto más amplio).

 Reducción de personal. La reducción es la migración de aplicaciones de mainframe a plataformas informáticas pequeñas.

Costos reducidos de infraestructura y hardware. Rentable: la disponibilidad de equipos informáticos de bajo coste y la creciente proliferación de redes de área local hacen que la tecnología cliente-servidor sea más rentable que otras tecnologías de procesamiento de datos. El equipo se puede actualizar tan pronto como surja la necesidad.

 Reducir el tiempo total de ejecución de la aplicación;

 Reducir el uso de memoria del cliente;

 Reducir el tráfico de la red.

Capacidad para trabajar con multimedia: hasta la fecha, se han creado muchos programas multimedia para PC. No existen tales programas para la configuración del host de la terminal o son muy costosos.
La capacidad de atraer grandes recursos informáticos para las operaciones de la base de datos: dado que las aplicaciones se ejecutan en las computadoras cliente, se liberan recursos adicionales (en comparación con la configuración terminal-host) en la computadora servidor para las operaciones de la base de datos, como los recursos informáticos del procesador central y memoria operativa.
Mejor productividad del programador: la productividad del programador aumenta mediante el uso de herramientas como SQL * Forms y CASE, que le permiten desarrollar aplicaciones más rápido que los lenguajes de programación como C, PL1 o COBOL.
Mayor productividad del usuario final: a estas alturas, muchos usuarios finales han dominado sistemas como Lotus, Paradox, Word Perfect, Harvard Graphics y más.

La interfaz del lado del servidor está definida y fija. Por lo tanto, es posible crear nuevas partes de cliente de un sistema existente (un ejemplo de interoperabilidad a nivel del sistema).

Arroz. 2.2. Ilustración del acceso de un cliente a un recurso compartido de servidor.

Cómo implementar la tecnología cliente-servidor

ordenador servidor de base de datos;
computadoras cliente;
red de comunicacion;
software de red;
Software de la aplicacion.

Arroz. 2.3. Esquema de ejecución de consultas de usuarios a bases de datos distribuidas.

El modelo de datos tiene tres componentes:

La estructura de datos a representar desde el punto de vista del usuario de la base de datos.
Operaciones válidas realizadas sobre la estructura de datos. Es necesario poder trabajar con esta estructura utilizando varias operaciones de NOD y NAM. Una estructura rica no tiene valor si no hay forma de manipular su contenido.
Restricciones de control de integridad. El modelo de datos debe contar con medios para mantener su integridad y protegerlo. Como ejemplo, considere las siguientes dos restricciones:
Cada subárbol debe tener un nodo de origen. Las bases de datos jerárquicas no pueden almacenar nodos secundarios sin un nodo de origen.
Con respecto a una base de datos relacional, no puede haber tuplas idénticas. Para un archivo, este requisito requiere que todos los registros sean únicos.

Una de las características más importantes de un DBMS es la capacidad de vincular objetos.

Existen los siguientes tipos de vínculos entre objetos:

Uno a uno (1: 1)... Un objeto de un conjunto se puede asociar con un objeto de otro conjunto.
Uno a varios (1: M)... Un objeto de un conjunto se puede asociar con muchos objetos de otro conjunto.
Muchos a muchos (M: N)... Un objeto de un conjunto se puede asociar con muchos objetos de otro conjunto, pero al mismo tiempo un objeto de otro conjunto se puede asociar con muchos objetos del primer conjunto.
Ramificado ... Un objeto de un conjunto puede asociarse con objetos de muchos conjuntos.
Recursivo ... Un objeto de un conjunto dado puede estar vinculado por un objeto del mismo conjunto.

Existen los siguientes modelos de datos básicos:

Modelo de datos relacionales.
Modelo de datos jerárquico.
Modelo de datos de red incompleto.
Modelo de datos CODASYL.
Modelo de datos de red extendido.

V .3. TECNOLOGÍAS INTERNET / INTRANET Y SOLUCIONES CORPORATIVAS DE ACCESO A BASES DE DATOS

Otros trabajos similares que te pueden interesar. Wshm>
6914.		Concepto de base de datos	11,56 KB
	La base de datos se presenta en forma objetiva, un conjunto de materiales independientes de artículos de cálculo de actos normativos de decisiones judiciales y otros materiales similares sistematizados de tal manera que estos materiales se pueden encontrar y procesar utilizando una computadora electrónica Código Civil de la Federación de Rusia Federación Art. Una base de datos organizada de acuerdo con ciertas reglas y mantenida en la memoria de la computadora es un conjunto de datos que caracterizan el estado actual de algunos ...
8064.		Bases de datos distribuidas	43,66 KB
	Bases de datos distribuidas Una base de datos distribuida RDB se entiende como un conjunto de datos compartidos interconectados lógicamente que se distribuyen físicamente en diferentes nodos de una red informática. El acceso a los datos no debe depender de la presencia o ausencia de réplicas de datos. El sistema debe determinar automáticamente los métodos para realizar la conexión de fusión de datos, el canal de red es capaz de hacer frente a la cantidad de información transmitida y el nodo tiene suficiente poder de procesamiento para unirse a las tablas. El RDBMS debe ser capaz de ...
20319.		BASES DE DATOS Y SU PROTECCIÓN	102,86 KB
	Las bases de datos en línea surgieron a mediados de la década de 1960. Las operaciones en las bases de datos operativas se procesaron de forma interactiva utilizando terminales. Las organizaciones de registros secuenciales de índices simples evolucionaron rápidamente a un modelo de registro orientado a conjuntos más poderoso. Charles Bachmann recibió el Premio Turing por liderar el Grupo de tareas de base de datos (DBTG), que desarrolló un lenguaje estándar para la descripción y manipulación de datos.
5031.		Biblioteca de desarrollo de bases de datos	11,72 MB
	Tecnología de diseño de bases de datos. Determinar relaciones entre entidades y crear un modelo de datos. Las ideas principales de la tecnología de la información moderna se basan en el concepto según el cual los datos deben organizarse en bases de datos para reflejar adecuadamente el mundo real cambiante y satisfacer las necesidades de información de los usuarios. Estas bases de datos se crean y operan bajo el control de sistemas de software especiales llamados sistemas de administración de bases de datos DBMS.
13815.		MODELO DE BASE DE DATOS JERÁRQUICA	81.62 KB
	Las ideas principales de la tecnología de la información moderna se basan en el concepto de bases de datos, según el cual la base de la tecnología de la información son los datos organizados en bases de datos que reflejan adecuadamente el estado de un área temática en particular y brindan al usuario información relevante en esta área temática. Debe reconocerse que los datos son ...
14095.		Desarrollo de bases de datos de bibliotecas	11,72 MB
	El aumento en el volumen y la complejidad estructural de los datos almacenados, la expansión del círculo de usuarios de los sistemas de información han llevado al uso generalizado del DBMS relacional (tabular) más conveniente y relativamente fácil de entender.
5061.		Creación de base de datos policlínica	2,4 MB
	El desarrollo de la tecnología informática y la tecnología de la información ha brindado oportunidades para la creación y el uso generalizado de sistemas de información automatizados (AIS) para diversos fines. Se están desarrollando e implementando sistemas de información para la gestión de instalaciones económicas y técnicas.
13542.		Bases de datos de información geológica	20,73 KB
	Recientemente, la introducción de tecnologías informáticas y, en particular, bases de datos, en el campo científico se ha producido rápidamente. Este proceso tampoco pasa por alto la geología, ya que es en las ciencias naturales donde existe la necesidad de almacenar y procesar grandes cantidades de información.
9100.		Base de datos. Conceptos básicos	26,28 KB
	Una base de datos es una colección de información sobre objetos específicos del mundo real en cualquier área temática de economía, administración, química, etc. El propósito de un sistema de información no es solo el almacenamiento de datos sobre objetos, sino también la manipulación de estos datos. , teniendo en cuenta las conexiones entre objetos. Cada objeto se caracteriza por un conjunto de datos de propiedades, que se denominan atributos en la base de datos.
5240.		Creación de la base de datos "Oficina del decano"	1,57 MB
	La base de datos (DB) es un conjunto de datos interconectados almacenados juntos en un medio de almacenamiento externo de una computadora, con una organización de este tipo y una redundancia mínima que les permite ser utilizados de manera óptima para una o varias aplicaciones.

Modelos de datos de la industria

Publicaciones

Steve Hoberman. Aprovechando el modelo de datos lógicos de la industria como su modelo de datos empresarial.
Claudia Imhoff. Proyectos de inteligencia empresarial y almacenamiento de datos de seguimiento rápido mediante el modelado inteligente de datos

Zaitsev S.L., Ph.D.

Grupos repetidos

Arroz. 1.6. Este ejemplo usa grupos repetidos.

Arroz. 1.7. Modelo reducido a la primera forma normal.

Un hecho en un solo lugar

Si el mismo atributo está presente en más de una entidad y no es una clave externa, este atributo se considera redundante. El modelo lógico no debe contener datos redundantes.

Cada atributo depende de la clave

Arroz. 1.9. En tercera forma normal Nombre de la escuela y Región geográfica transferidos a entidad, donde sus valores dependen de la clave.

Relaciones de muchos a muchos

Definiciones formales de formas normales.

La relación R corresponde a la primera forma normal (1NF) si y solo si todos los dominios que le pertenecen contienen solo valores atómicos (Fecha, ibid.).

Una relación R corresponde a la segunda forma normal (2NF) si y solo si corresponde a 1NF, y cada atributo que no es clave es completamente dependiente de la clave primaria (Fecha, ibid.).

Una relación R corresponde a la tercera forma normal (3NF) si y solo si corresponde a 2NF, y cada atributo que no es clave no depende transitivamente de la clave primaria (Fecha, ibid.).

La relación R corresponde a la forma normal de Boyes-Codd (BCNF) si y solo si cada determinante es candidato para usarse como clave.

NOTA A continuación se muestra una breve explicación de algunas de las abreviaturas utilizadas en las definiciones de Date.

FD (dependencia funcional) - dependencia funcional. Con la dependencia funcional, el valor de un atributo depende del valor de otro atributo que no es parte de la clave primaria.

Formas comerciales normales

La tercera forma normal de negocio (3BNF) toma atributos que son independientes de una clave primaria en otra entidad, donde son completamente dependientes de la clave primaria de esa entidad.

Modelo de datos lógicos completado

Modelo de datos físicos

Recopilación de requisitos de uso de datos

Requisitos de acceso y rendimiento

Características volumétricas (una estimación de la cantidad de datos a almacenar) que permiten al administrador representar el volumen físico de la base de datos.

Estimar la cantidad de usuarios que necesitan acceso simultáneo a los datos para ayudarlo a diseñar su base de datos para niveles de rendimiento aceptables.

Agregados, pivotes y otros datos calculados o derivados que pueden considerarse candidatos para el almacenamiento en estructuras de datos persistentes.

Requisitos para informes y consultas estándar para ayudar al administrador de la base de datos a crear índices.

Vistas (persistentes o virtuales) que ayudarán al usuario a realizar operaciones de agregación o filtrado de datos.

Componentes del modelo de datos físicos

Ingeniería inversa

Usar límites funcionales corporativos

¿Qué es un modelo de datos empresarial?

Construyendo un modelo de datos corporativos aumentando

Concepto de metodología de modelado

Existen varias metodologías de modelado de datos visuales. ERwin admite dos:

IDEF1X (Definición de integración para modelado de información: descripción integrada de modelos de información).

IE (Ingeniería de la información).

IDEF1X es una buena metodología y el uso de su notación está muy extendido

Descripción integrada de modelos de información

Ingeniería de Información

Conclusión

NOTA Pluralidad La relación describe el número máximo de instancias de entidad secundaria que se pueden asociar con una instancia de la entidad original.Necesidad de existencia o posibilidad de ausencia La relación sirve para determinar el número mínimo de instancias de una entidad secundaria que se puede asociar con una instancia del original.

Enviar tu buen trabajo en la base de conocimientos es simple. Utilice el siguiente formulario

Los estudiantes, estudiantes de posgrado, jóvenes científicos que utilizan la base de conocimientos en sus estudios y trabajos le estarán muy agradecidos.

Publicado en http://www.allbest.ru/

1. Modelo de datos relacionales

1.1 El modelo de datos relacionales. Definiciones basicas
1.2 Operaciones sobre relaciones

2. Sistemas de información corporativa
Bibliografía

1. Modelo de datos relacionales

1.1 El modelo de datos relacionales. Definiciones basicas

En las disciplinas matemáticas, el concepto de "tabla" corresponde al concepto de "relación" (relación). La tabla refleja un objeto del mundo real, una entidad, y cada una de sus líneas refleja una instancia específica de la entidad. Cada columna tiene un nombre exclusivo de la tabla. Las cadenas no tienen nombre, su orden no está definido y el número es lógicamente ilimitado. Una de las principales ventajas del modelo de datos relacionales es la homogeneidad (cada fila de una tabla tiene el mismo formato). Depende del usuario decidir si las respectivas entidades son homogéneas. Esto resuelve el problema de la idoneidad del modelo.

Conceptos básicos:

* Una relación es una tabla bidimensional que contiene algunos datos.

* Entidad: un objeto de cualquier naturaleza, cuyos datos se almacenan en la base de datos. Los atributos son propiedades que caracterizan a una entidad (columnas).

* El grado de relación es el número de columnas.

* Esquema de relación: una lista de nombres de atributos, por ejemplo, EMPLEADO (No., nombre completo, año de nacimiento, cargo, departamento).

* Dominio: un conjunto de valores de los atributos de una relación (tipo de datos).

* Una tupla es una fila de una tabla.

* Cardinalidad (cardinalidad): el número de filas en la tabla.

* La clave principal es un atributo que identifica de forma única las filas de una relación. Una clave principal de atributos múltiples se denomina clave principal compuesta. La clave principal no puede estar total o parcialmente vacía (nula). Las claves que se pueden utilizar como claves primarias se denominan claves potenciales o alternativas.

* Una clave externa es un atributo (s) de una tabla que puede servir como clave principal de otra tabla. Hace referencia a la clave principal de otra tabla.

La normalización es un proceso destinado a reducir la redundancia de información en una base de datos. Además de los datos en sí, también se pueden normalizar varios nombres, nombres de objetos y expresiones en la base de datos.

Una base de datos no normalizada contiene información en una o más tablas diferentes; esto da la impresión de que la inclusión de datos en una tabla en particular no se debe a razones aparentes. Esta situación puede tener un impacto negativo en la seguridad de los datos, el uso racional del espacio en disco, la velocidad de las consultas, la eficiencia de la actualización de la base de datos y, quizás lo más importante, la integridad de la información almacenada. La base de datos antes de la normalización es una estructura que, lógicamente, todavía no se ha dividido en tablas más pequeñas y más manejables.

La forma normal es una especie de indicador del nivel o profundidad de la normalización de la base de datos. El nivel de normalización de la base de datos corresponde a la forma normal en la que se encuentra.

1.2 Operaciones sobre relaciones

Para llevar la mesa a la primera forma normal (1NF), se deben observar dos reglas:

1. Atomicidad o indivisibilidad. Cada columna debe contener un valor indivisible.

2. La tabla no debe contener columnas o grupos de datos duplicados.

Por ejemplo, si una tabla contiene en un campo la dirección completa de una persona (calle, ciudad, código postal), no cumplirá con las reglas 1NF, ya que contendrá diferentes valores en una columna, lo que sería una infracción. de la regla de la atomicidad. O si la base de datos contiene datos sobre películas y contiene las columnas Actor1, Actor2, Actor3, tampoco cumplirá con las reglas, ya que los datos se repetirán.

La normalización debe comenzar con la verificación de la estructura de la base de datos para verificar su compatibilidad con 1NF. Todas las columnas que no son atómicas deben dividirse en sus columnas constituyentes. Si hay columnas duplicadas en la tabla, entonces deben seleccionar una tabla separada.

Para llevar la tabla a la primera forma normal, debe:

* Busque todos los campos que contienen información de varias partes.

* Los datos que se pueden desglosar en partes componentes deben colocarse en campos separados.

* Mueva los datos duplicados a una tabla separada.

* Compruebe si todas las tablas coinciden con las condiciones del primer formulario normal.

Para llevar las tablas a la segunda forma normal (2NF), las tablas ya deberían estar en 1NF. La normalización debe continuar en orden.

Ahora, en la segunda forma normal, se debe cumplir la condición: cualquier columna que no sea una clave (incluida la externa) debe depender de la clave principal. Normalmente, estas columnas, que tienen valores que son independientes de la clave, son fáciles de identificar. Si los datos contenidos en la columna no están relacionados con la clave que describe la fila, entonces deben separarse en su propia tabla separada. La clave principal debe devolverse a la tabla anterior.

Para llevar la base a la segunda forma normal, necesita:

* Identifique todas las columnas que no dependen directamente de la clave principal de esta tabla.

* Cree los campos obligatorios en las tablas de usuarios y foros, seleccione de los campos existentes o cree claves primarias a partir de los nuevos.

* Cada tabla necesita su propia clave principal

* Crear claves foráneas y designar sus relaciones entre tablas. El paso final de la normalización a 2NF será la asignación de claves externas para la comunicación con las tablas asociadas. La clave principal de una tabla debe ser una clave externa en otra.

Sugerencias:

Otra forma de convertir un esquema a 2NF es observar las relaciones entre las tablas. Idealmente, cree todas las relaciones de uno a varios. Las relaciones de muchos a muchos necesitan reestructurarse.

Una tabla correctamente normalizada nunca tendrá filas duplicadas (dos o más filas cuyos valores no son claves y contienen los mismos datos).

La base de datos estará en la tercera forma normal si se convierte a la segunda forma normal y cada columna no clave es independiente entre sí. Si sigue el proceso de normalización correctamente hasta este punto, es posible que no haya dudas sobre la conversión a 3NF. Debe tener en cuenta que se infringe 3NF si cambiar el valor en una columna requiere un cambio en la otra columna.

Para llevar la base a la tercera forma normal, necesita:

* Determinar qué campos de qué tablas tienen interdependencias, es decir campos que dependen más entre sí que de la fila en su conjunto.

* Crea tablas coincidentes. Si hay una columna problemática en el paso 1, cree tablas divididas para ella.

* Crear o asignar claves primarias. Cada tabla debe tener una clave principal.

* Cree las claves externas necesarias que formen cualquiera de las relaciones.

En la cuarta forma normal, una regla adicional es que es necesario excluir las dependencias multivalor. En otras palabras, todas las filas de la tabla deben ser independientes entre sí. La presencia de alguna fila X no debería significar que la fila Y también esté en algún lugar de esta tabla.

2. Sistemas de información institucional

sistema de datos modelo relacional

Un sistema (del griego systema, un todo, un compuesto formado por partes) es un conjunto de elementos que interactúan entre sí, formando una cierta integridad, unidad. A continuación, se muestran algunos conceptos que se utilizan a menudo para caracterizar un sistema.

1. Un elemento del sistema es parte de un sistema que tiene un propósito funcional específico. Los elementos complejos de los sistemas, a su vez, que consisten en elementos interconectados más simples, a menudo se denominan subsistemas.

2. Organización del sistema: orden interno, coherencia de la interacción de los elementos del sistema, que se manifiesta, en particular, en la limitación de la variedad de estados de los elementos dentro del sistema.

3. La estructura del sistema: la composición, el orden y los principios de interacción de los elementos del sistema, que determinan las propiedades básicas del sistema. Si los elementos individuales del sistema están espaciados en diferentes niveles y las conexiones internas entre los elementos están organizadas solo de niveles superiores a inferiores y viceversa, entonces hablamos de la estructura jerárquica del sistema. Las estructuras puramente jerárquicas son prácticamente raras, por lo que, ampliando algo este concepto, la estructura jerárquica suele entenderse como aquellas estructuras en las que, entre otras conexiones, las relaciones jerárquicas son de primordial importancia.

4. Arquitectura del sistema: un conjunto de propiedades del sistema que son esenciales para el usuario.

5. Integridad del sistema: la irreductibilidad fundamental de las propiedades del sistema a la suma de las propiedades de sus elementos individuales (aparición de propiedades) y, al mismo tiempo, la dependencia de las propiedades de cada elemento en su lugar y función dentro del sistema.

El sistema de información es un conjunto interconectado de medios, métodos y personal que se utiliza para almacenar, procesar y emitir información con el fin de lograr el objetivo establecido "

La Ley Federal de "Información, Informatización y Protección de la Información" proporciona la siguiente definición:

"El sistema de información es un conjunto de documentos (conjuntos de documentos) y tecnologías de la información ordenados organizativamente, incluido el uso de tecnología informática y comunicaciones que implementan procesos de información"

Clasificación de escala

En términos de escala, los sistemas de información se dividen en los siguientes grupos:

* soltero;

* grupo;

* corporativo.

Un sistema de información corporativa es un sistema escalable diseñado para la automatización integrada de todo tipo de actividades económicas de las grandes y medianas empresas, incluidas las corporaciones constituidas por un grupo de empresas que requieren una gestión unificada.

Un sistema de información corporativo puede considerarse un sistema que automatiza más del 80% de las divisiones de una empresa.

Recientemente, en muchas publicaciones dedicadas al uso de la tecnología de la información en la gestión de objetos económicos, se utiliza con frecuencia el término "sistemas de información empresarial", que en ellas significa los sistemas de información automatizados reales de objetos económicos.

Un sistema de información automatizado (AIS) es una combinación de varios tipos de soporte, así como especialistas diseñados para automatizar el procesamiento de información contable y analítica. Como regla general, los tipos de soporte son homogéneos para diferentes sistemas en composición, lo que permite implementar el principio de compatibilidad de sistemas en el curso de su funcionamiento. En el proceso de estudiar AIS como un sistema complejo, es necesario destacar partes y elementos individuales y considerar las características de su uso en las etapas de creación y operación.

Los sistemas de información corporativa son una evolución de los sistemas para grupos de trabajo, están enfocados a grandes empresas y pueden soportar nodos o redes dispersas geográficamente. Básicamente, tienen una estructura jerárquica de varios niveles. Estos sistemas se caracterizan por una arquitectura cliente-servidor con especialización de servidores o una arquitectura multinivel. Al desarrollar dichos sistemas, se pueden utilizar los mismos servidores de bases de datos que al desarrollar sistemas de información de grupo. Sin embargo, en los grandes sistemas de información, los servidores más comunes son Oracle, DB2 y Microsoft SQL Server.

Para los sistemas corporativos y grupales, los requisitos para la confiabilidad de la operación y la seguridad de los datos aumentan significativamente. Estas propiedades se mantienen manteniendo los datos, la referencia y la integridad transaccional en los servidores de la base de datos.

Clasificación por alcance

Según el ámbito de aplicación, los sistemas de información suelen dividirse en cuatro grupos:

* sistemas de procesamiento de transacciones;

* sistemas de toma de decisiones;

* sistemas de información y referencia;

* sistemas de información de oficina.

Bibliografía

1. Agaltsov, V.P. Base de datos. En 2 volúmenes V. 2. Bases de datos distribuidas y remotas: Libro de texto / V.P. Agaltsov. - M.: ID FORUM, NITs INFRA-M, 2013.

2. Golitsyna, O. L. Bases de datos: Libro de texto / O.L. Golitsyna, N.V. Maksimov, I.I. Popov. - M.: Foro, 2012.

3. Karpova, I.P. Bases de datos: Libro de texto / I.P. Karpov. - SPb.: Peter, 2013.

4. Kirillov, V.V. Introducción a las bases de datos relacionales Introducción a las bases de datos relacionales. Kirillov, G.Yu. Gromov. - SPb.: BHV-Petersburg, 2012.

5. Pirogov, V.Yu. Sistemas de información y bases de datos: organización y diseño: Libro de texto / V.Yu. Pirogov. - SPb.: BHV-Petersburg, 2009.

6. G.N. Fedorov. Sistemas de información. - M.: Academia, 2013.

7. A.E. Satunina, L.A. Sysoeva. Gestión de proyectos del sistema de información corporativa de la empresa. - M.: Finanzas y estadísticas, Infra-M, 2009.

Publicado en Allbest.ru

...

Documentos similares

La esencia y características de los tipos de modelos de datos: jerárquico, de red y relacional. Conceptos básicos del modelo de datos relacionales. Atributos, esquema de relación de la base de datos. Condiciones de integridad de los datos. Relaciones entre tablas. Comprensión general del modelo de datos.

trabajo de término, agregado 29/01/2011

Bases de datos y sistemas de información corporativa, su uso para mejorar y depurar negocios. Clasificación de sistemas de información corporativos. Sistemas de información de clase OLTP. Procesamiento analítico rápido.

trabajo final agregado 19/01/2011

Bases de datos con archivos bidimensionales y sistemas de gestión de bases de datos relacionales (DBMS). Creando una base de datos y procesando consultas a ellos usando un DBMS. Los principales tipos de bases de datos. Conceptos básicos de bases de datos relacionales. Propiedades fundamentales de las relaciones.

resumen, agregado 20/12/2010

Concepto de sistema de base de datos. El modelo relacional y sus características. Integridad en el modelo relacional. Álgebra relacional. Problemas de diseño de bases de datos. Formas normales de relaciones. Diseñar una base de datos utilizando el método entidad-relación. Diagramas ER. Lenguaje SQL.

curso de conferencias agregado el 10/03/2008

Una estructura lógica definida de datos que se almacena en una base de datos. Modelos de datos básicos. Elementos del modelo de datos relacionales. Un ejemplo de uso de claves externas. Requisitos básicos para la relación del modelo de datos relacionales.

presentación agregada el 14/10/2013

Bases de datos y su uso en informática. Características y unidad constructiva básica del modelo de datos de red. Modelo jerárquico, objetos del área temática. Modelo relacional, su visibilidad, presentación de datos en forma tabular.

resumen, agregado 19/12/2011

Tipos y funciones del sistema de gestión de bases de datos de Microsoft Access. Modelo relacional jerárquico, de red para describir bases de datos. Conceptos básicos de una tabla de base de datos. Características de la creación de objetos de base de datos, formas básicas. Acceso a Internet en Access.

prueba, agregada el 01/08/2011

Sistemas modernos de gestión de bases de datos (DBMS). Análisis del modelo jerárquico de datos. Modelo de datos relacionales. Modelo de datos post-relacional como un modelo relacional extendido que elimina la restricción sobre la indivisibilidad de los datos almacenados en los registros de la tabla.

trabajo científico, añadido el 08/06/2010

Modelos de datos en la gestión de bases de datos. Modelos de datos conceptuales. El papel de las bases de datos en los sistemas de información. Modelo de datos relacionales. Definición del área temática. Construcción de un modelo de base de datos para el sistema de información "Mascotas".

trabajo de término, agregado 19/04/2011

Modelo de información en Access como una especie de sustituto simplificado de un objeto o sistema real. Estructuras básicas que determinan la organización de los datos y las relaciones entre ellos; un tipo relacional de organización de datos. Un ejemplo de base de datos en tributación.

El modelo de datos empresariales incluye elementos. Modelo de datos relacionales

"El cuento es una mentira, pero hay una pista en él ..."

Interrogación

Antifragilidad

¿Qué es un almacén de datos y por qué lo estamos construyendo?

Funciones clave de los almacenes de datos

Concepto arquitectónico

Núcleo del sistema

Modelo básico de almacén y modelo de datos empresariales

Capa de datos primaria (o capa operativa o de ensayo historizada)

Capa de escaparate

Capa de servicio

Diseño y mantenimiento de modelos de datos de almacén

Características de los proyectos de almacenamiento de datos

El almacén de datos es un software personalizado

El almacén de datos es un proyecto de integración

El almacén de datos es un proyecto colaborativo

El almacén de datos tiene una vida útil más larga que otros sistemas.

Desarrollo iterativo gradual

Almacenes de datos: "historia de varios proyectos"

Equilibrio de innovación y soluciones probadas

Epílogo

Epílogo

Modelos de datos de la industria

Publicaciones

TEMA V. BASES DE DATOS CORPORATIVAS

Modelo de datos empresariales

Introducción

Modelo de datos empresariales

Niveles de presentación del modelo de datos empresariales

TEMA V. BASES DE DATOS CORPORATIVAS

Modelos de datos de la industria

Publicaciones

Enviar tu buen trabajo en la base de conocimientos es simple. Utilice el siguiente formulario

1. Modelo de datos relacionales

2. Sistemas de información institucional

sistema de datos modelo relacional

Un sistema (del griego systema, un todo, un compuesto formado por partes) es un conjunto de elementos que interactúan entre sí, formando una cierta integridad, unidad. A continuación, se muestran algunos conceptos que se utilizan a menudo para caracterizar un sistema.

1. Un elemento del sistema es parte de un sistema que tiene un propósito funcional específico. Los elementos complejos de los sistemas, a su vez, que consisten en elementos interconectados más simples, a menudo se denominan subsistemas.

2. Organización del sistema: orden interno, coherencia de la interacción de los elementos del sistema, que se manifiesta, en particular, en la limitación de la variedad de estados de los elementos dentro del sistema.

4. Arquitectura del sistema: un conjunto de propiedades del sistema que son esenciales para el usuario.

5. Integridad del sistema: la irreductibilidad fundamental de las propiedades del sistema a la suma de las propiedades de sus elementos individuales (aparición de propiedades) y, al mismo tiempo, la dependencia de las propiedades de cada elemento en su lugar y función dentro del sistema.

El sistema de información es un conjunto interconectado de medios, métodos y personal que se utiliza para almacenar, procesar y emitir información con el fin de lograr el objetivo establecido "

La Ley Federal de "Información, Informatización y Protección de la Información" proporciona la siguiente definición:

"El sistema de información es un conjunto de documentos (conjuntos de documentos) y tecnologías de la información ordenados organizativamente, incluido el uso de tecnología informática y comunicaciones que implementan procesos de información"

Clasificación de escala

En términos de escala, los sistemas de información se dividen en los siguientes grupos:

* soltero;

* grupo;

* corporativo.

Un sistema de información corporativa es un sistema escalable diseñado para la automatización integrada de todo tipo de actividades económicas de las grandes y medianas empresas, incluidas las corporaciones constituidas por un grupo de empresas que requieren una gestión unificada.

Un sistema de información corporativo puede considerarse un sistema que automatiza más del 80% de las divisiones de una empresa.

Para los sistemas corporativos y grupales, los requisitos para la confiabilidad de la operación y la seguridad de los datos aumentan significativamente. Estas propiedades se mantienen manteniendo los datos, la referencia y la integridad transaccional en los servidores de la base de datos.

Clasificación por alcance

Según el ámbito de aplicación, los sistemas de información suelen dividirse en cuatro grupos:

* sistemas de procesamiento de transacciones;

* sistemas de toma de decisiones;

* sistemas de información y referencia;

* sistemas de información de oficina.

Bibliografía

Documentos similares

Recuperación de contraseña