Almacén de documentos en la nube de SAP HANA: ¿cuándo usaría un almacén de documentos?

Hay una serie de publicaciones de blog maravillosas aquí en el Comunidad SAP hablando de cómo puede empezar con Almacén de documentos en la nube de SAP HANAy lo que puedes hacer con él

Para esta publicación de blog, quería conocer principiantes absolutos Dónde están:

• Presentar las consideraciones de diseño detrás del uso de la más familiar Tiendas relacionales (filas y columnas)
• Discutir dónde podemos encontrarnos con desafíos al usar Tiendas Relacionales
• Mirando donde un Almacén de documentos podría ayudar
• explicando en un nivel alto qué Almacén de documentos en la nube de SAP HANA es

Esta publicación de blog pretende ser una introducción de alto nivel: no abordará todas las consideraciones de diseño y simplificará cuando sea posible. Los que buscan más artículos técnicos en profundidad puede encontrar algunas recomendaciones en Otros recursos al final de esta publicación

Cuando se trabaja con una base de datos utilizando Tiendas Relacionales, queremos comenzar por decidir cómo organizaremos y estructuraremos nuestros datos. Esta estructura se denomina Modelo de datos

Para recapitular de forma muy simplificada Modelo de datos relacionalesveamos cómo podemos almacenar información sobre un libro

Nuestros datos de libros simplificados

Puede describir este libro de muchas otras maneras: puede ser marrón, puede venderse en tapa dura y puede tener 388 páginas.

Solo queremos almacenar información que será útil para nuestro negocio. Para nuestro ejemplo, la lista anterior será suficiente

Con una comprensión de qué información nos importa, sabemos qué necesitaremos almacenar en un Tabla de base de datos. Alguien que analice este problema por primera vez podría esbozar un mesa como a continuación

Una tabla inicial

un libro ISBN es único – cada uno ISBN se refiere exactamente a un libro publicado. Esta singularidad nos permite utilizar la ISBN como algo llamado Clave primaria (indicado por el símbolo de llave)

Al mirar nuestro Columna de clave principal (en este caso ISBN), podemos decir de qué libro se trata cada fila de datos

Sin saberlo mejor, desplegamos nuestra tabla en una base de datos y la gente comienza a usarla. En poco tiempo, nuestros colegas acuden a nosotros con problemas

Desafíos con “One Central Table”

Un colega quiere buscar todos los libros escritos por Cameron Swift. Excepto que resulta que hay más de una persona en el mundo llamada Cameron Swift

Para ayudar a diferenciarlos, agregamos un Identificación del autor eso es unico para cada uno Autor. Mientras estamos en eso, damos nuestro Editores a ID de editor también

Agregar ID a nuestra tabla

Un segundo colega quiere entrar a libro con dos autores.En teoría, podríamos añadir otro conjunto de Columnas ID y nombre del autor. Desafortunadamente, eso no nos ayudará cuando necesitemos ingresar un libro con tres autoresy mucho menos cuatro o más autores

Para ayudarnos a almacenar estos datos, comenzamos por separar los datos en múltiples mesas. Movemos el Autor y Editor datos en su propio mesas

Dividir nuestros datos en tablas de libros, autores y editores

Como podemos ver arriba, el Identificación del autor y ID de editor también identificar de forma única cada fila en nuestro Autores y Editores mesas. Estos son los Claves primarias para esas tablas, de la misma manera que ISBN es para nuestro Libros mesa

Datos “relacionales”

No tiene sentido almacenar nuestros datos en diferentes tablas a menos que sepamos cómo están vinculados para que podamos recuperarlos.

Aquí es donde el término Datos relacionales proviene – para dar sentido a los datos, necesitamos entender nuestra mesas y el Relaciones entre esos mesas

La forma en que representamos esta relación es agregando el Clave primaria de uno mesa como un columna en otro mesa

Como ejemplo, vamos a vincular el Tabla de editores para nuestro Mesa de libros al incluir la clave principal para nuestro Tabla de editores (la ID de editor) como una columna en nuestro Mesa de libros

Vinculación de nuestras tablas de libros y editoriales

Al hacer coincidir el Columnas de ID de editor De nuestros Libros y Tablas de editores, ahora podemos encontrar fácilmente el editor de cada libro. Ahora que entendemos cómo funciona esto para Editorespodemos mirar nuestra Autores

Incluyendo múltiples autores

Cuando pensamos en incluir el ID de autor dentro de nuestra mesa de libros, puede parecer que tenemos el mismo problema con el que comenzamos. Como mostramos anteriormente, no podemos incluir múltiples ID de autor en nuestro Mesa de librosporque puede haber cualquier número de Autores (con la excepción de cero, porque los libros no se escriben solos)

Necesitamos crear un tercera mesa para vincular nuestro Libros y Tablas de autores. Nos referiremos a esto como un Tabla de vinculación. Esta tabla es una lista de ISBN y asociado ID de autor

Nuestra tabla BooksAuthored vincula las tablas Books y Authors

Porque un libro puede tener muchos autores y un autor puede escribir muchos librosninguna columna aquí es único. Esto es por diseño

Comenzando con el ISBN para cualquier dado libro, entonces podemos mirar en nuestro Tabla de vinculación. Cada fila con una coincidencia ISBN apunta a un autor de ese libro

Usar este enfoque significa que no tenemos que hacer ningún cambio en el estructura de nuestro mesas a medida que agregamos múltiples aautores. Por cada adicional autor, simplemente agregamos otra fila a nuestro Tabla de vinculación

Nuestra estructura de datos completa para almacenar este ejemplo simplificado se vería así:

Nuestra estructura de datos completa

Trabajar a través de estos desafíos deja algo muy claro:

cuando es nuevo requisitos comerciales surgir, estos podran requerir cambios en nuestro subyacente modelo de datos. Como vimos anteriormente: incluso con un escenario simplificado: cambiar modelos de datos no es una tarea trivial

No podemos cambiar el conjunto de columnas para una sola fila: todas las filas dentro de una tabla usan el mismo conjunto de columnas

Los requisitos comerciales a menudo requieren cambios en nuestros modelos de datos

Dependiendo del alcance del cambio requerido, podríamos considerar agregar columnas a una sola tabla (como hicimos con Identificación del autor y ID de editor), o cambios más complejos que requieren volver a mapear nuestros datos en varias tablas

En este caso, es probable que necesitemos actualizar la lógica que escribe y lee en estas tablas: en todas partes los usamos

¿Significa esto que almacenar datos en Relacional Historias es una mala idea? Absolutamente no. Existen beneficios en el almacenamiento de datos de esta manera: a menudo queremos hacer cumplir una conocido, esquema fijo y queremos que cualquier variación sea considerada y aprobada. Aquí es donde Almacenamiento de datos relacionales podría ser el mejor ajuste

Por otro lado, hay momentos en los que el enfoque fijo de columnas y tablas predefinidas no es la mejor manera de almacenar nuestros datos

Tal vez queremos almacenar datos anidados – por ejemplo, nuestros libros donde podemos tener cualquier número de autores – sin dividir los datos entre diferentes tablas

Tal vez estamos recibiendo datos de Nube API: si estamos recibiendo datos de API de Ariba, los datos no se nos devuelven como entradas listas para ser almacenadas en una tabla. En su lugar, es probable que obtengamos resultados formateados en algo llamado JSON (Notación de objetos de JavaScript)

Documentos JSON

El término Documento JSON se usa para describir cualquiera Objetos JSON o Matrices JSON. Solo vamos a describir Objetos JSON en esta entrada de blog

Dentro de nuestro Objetos JSONtenemos una serie de Pares clave/valor. Por ejemplo, [Book] Título es un Llavey el Valor porque esto podría ser Almacenamiento de documento. Repasemos nuestro ejemplo anterior

Estructura relacional (tabla) frente a estructura de documento JSON

Arriba podemos ver cómo las propiedades de un libro podrían modelarse en un Mesa o Documento JSON. Nuestro Documento JSON es un objeto entre llaves { }, hecho de un número de Pares clave/valor

El documento JSON es autodescriptivo. Es decir, si recuperamos los datos del libro, podemos verificar el llaves decir lo que cada uno valor representa. Si recuperamos una sola fila de datos de una tabla, los nombres de las columnas no se incluyen de forma predeterminada

Recuperación de datos de libros de almacenes relacionales y de documentos

Con nuestro pequeño número de columnas, esto es factible. ¿Seremos capaces de recordar cincuenta columnas? ¿Un centenar? Nadie tiene ese tipo de paciencia.

Colecciones JSON

Porque nuestro Documentos JSON almacenar la estructura junto con los datos, podemos fácilmente variar la estructura entre entradas. A diferencia de filas almacenado en un tabla, Documentos JSON se almacenan en algo llamado Colección JSON

Para ayudarnos a entender esto, podemos imaginar cada Documento JSON como una hoja de papel física con nuestros datos escritos en ella

Trabajando con una hoja de papel en blanco, podemos escribir nuestros datos exactamente como es – no necesitamos ceñirnos a un formato fijo

Las hojas de papel sueltas no son buenas para el almacenamiento y la recuperación, por lo que almacenamos nuestros documentos relacionados en una carpeta Manila. Esta carpeta es nuestra Colección JSON

Documentos y colecciones JSON

Cuando almacenas un documento JSON, lo pones en un relacionado Colección JSON. Cuando quieras acceder a la Documento más tarde, lo recuperas del mismo Recopilación

Usando Documento en la nube de SAP HANA Tienda, podemos hacer esto usando una sintaxis SQL modificada. Pero esa es una historia para otra, más técnica. entrada en el blog

Almacenamiento y recuperación de documentos

En esta publicación de blog hemos discutido Almacenamiento relacional usando Mesas, incluyendo los beneficios y limitaciones de trabajar con un estructura de datos conocida y fija

También hemos discutido cómo podemos trabajar con datos que no se ajustan a una estructura fija usando Documentos JSON, almacenado en el interior Colecciones JSON

Como siempre, la realidad práctica es más compleja que la teoría. Con suerte, esta ha sido una introducción útil de alto nivel sobre cuándo podría usar un Almacén de documentos como Almacén de documentos en la nube de SAP HANA

Doy la bienvenida a cualquier pregunta o comentario a continuación

Para más Aplicación práctica:

Tal vez le gustaría saber cómo puede activar Almacén de documentos de SAP HANA dentro Nube SAP HANA

Habilitación del almacén de documentos JSON por cameron rápido

Quizás ya hayas activado Almacén de documentos de SAP HANA y quiero obtener algo de experiencia con insertando y seleccionando Documentos JSON

HANA DocStore Primeros pasos por cameron rápido

Para más Teoría:

Es posible que haya escuchado el término Bases de datos NoSQL antes de. El almacén de documentos es un tipo de la base de datos NoSQL, pero no es el solo tipo. Tal vez le gustaría aprender acerca de otro tipo de base de datos no SQL, la Base de datos de gráficos

Base de datos de SAP HANA como almacén de gráficos: introducción por Poorna Malamandi Suresh

Habilitación del almacén de documentos JSON por cameron rápido

HANA DocStore Primeros pasos por cameron rápido

El pequeño libro de cocina del almacén de documentos JSON por Mathias Kemeter

Destacado: SAP HANA Cloud JSON Document Store por Laura Nevin

El almacén de documentos SAP HANA JSON: introducción (parte 1) por Kai Müller

Ariba Analytics con SAP Analytics Cloud, Data Intelligence Cloud y HANA DocStore – Parte 1 por cameron rápido

Nota: Si bien soy un empleado de SAP, todas las opiniones/ideas son mías y no reflejan necesariamente las de mi empleador.