El modelo relacional organiza los datos en una o más tablas (o "relaciones") de columnas y filas, mediante una clave única para identificar cada fila. Las filas también se llaman registros o tuplas.
Obtener más información sobre los modelos de datos relacionales.
InterSystems Data Platform (IDP) es compatible con las tablas relacionales como parte del concepto de modelos de almacenamiento múltiples. La IDP proporciona acceso al SQL y a la API de las tablas relacionales.
Al comenzar con InterSystems IRIS o Caché, los desarrolladores a menudo se encuentran con tres conceptos fundamentales: Dynamic Objects, Globals y Relational Table. Cada uno tiene su papel en la construcción de soluciones escalables y mantenibles. En este artículo recorreremos ejemplos prácticos de código, destacaremos buenas prácticas y mostraremos cómo estos conceptos se relacionan entre sí.
1. Trabajando con Dynamic Objects:
De cara a la reconstrucción de los índices de una clase persistente/tabla, hay que utilizar el método %BuildIndices(), proporcionado por dicha clase. Para ello hay que especificar los valores de inicio y fin de los ID para los cuales se quieren reconstruir índices en los argumentos del método.
Por ejemplo, para reconstruir el índice NameIDX y el índice ZipCode en la clase Sample.Person sólo para ID=10 a 20, ejecutad el siguiente código (el rango de ID se especifica en los argumentos quinto y sexto).
InterSystems IRIS actualmente limita sus clases a 999 propiedades.
Pero, ¿qué hacer si necesita almacenar más datos por objeto?
Este artículo respondería a esta pregunta (con el apunte adicional de Community Python Gateway y cómo transferir conjuntos de datos amplios a Python).
En realidad, la respuesta es muy simple: InterSystems IRIS actualmente limita las clases a 999 propiedades, pero no a 999 primitivas. La propiedad en InterSystems IRIS puede ser un objeto con 999 propiedades y así sucesivamente; el límite se puede ignorar fácilmente.
Antes de empezar a hablar de bases de datos y de los distintos modelos de datos que existen, primero explicaré qué es una base de datos y cómo se utiliza.
Una base de datos es una colección organizada de datos, almacenados y accesibles de forma electrónica. Se utiliza para almacenar y recuperar datos estructurados, semiestructurados o sin procesar, que normalmente están relacionados con un tema o una actividad.
En el corazón de toda base de datos hay al menos un modelo utilizado para describir sus datos. Y según el modelo que utilice, una base de datos puede tener características ligeramente diferentes y almacenar distintos tipos de datos.
Para escribir, recuperar, modificar, ordenar, transformar o imprimir la información de la base de datos, se utiliza un software llamado Sistema de Gestión de Bases de Datos (DBMS, por sus siglas en inglés).
El tamaño, la capacidad y el rendimiento de las bases de datos y sus respectivos DBMS ha aumentado de forma significativa. Esto ha sido posible gracias a los avances tecnológicos en varios ámbitos, como los procesadores, la memoria y almacenamiento de los ordenadores y las redes informáticas. En general, el desarrollo de la tecnología de bases de datos puede dividirse en cuatro generaciones basadas en los modelos o la estructura de los datos: navegacional, relacional, de objetos y post-relacionales.
A diferencia de las tres primeras generaciones, que se caracterizan por un modelo de datos específico, la cuarta generación incluye muchas bases de datos diferentes basadas en distintos modelos, como columnas, gráficos, documentos, componentes, multidimensiones, clave-valor, almacenamiento en memoria, etc. Todas estas bases de datos están unidas por un único nombre NoSQL (NoSQL o ahora es más preciso decir No sólo SQL).
Además, ahora aparece una nueva clase, que se llama NewSQL. Se trata de bases de datos relacionales modernas que tienen como objetivo ofrecer el mismo rendimiento escalable que los sistemas NoSQL para cargas de trabajo de procesamiento de transacciones en línea (lectura-escritura), a la vez que utilizan SQL y mantienen ACID.
Por casualidad, entre estas bases de datos de cuarta generación se encuentran las que admiten los modelos de datos múltiples mencionados anteriormente. Se llaman bases de datos multimodelo. Un buen ejemplo de este tipo de base de datos es InterSystems IRIS. Por ello, la utilizaré para dar ejemplos de distintos tipos de modelos, según vayan presentándose.
<iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="" src="https://www.youtube.com/embed/EAOfw09xTrM" title="YouTube video player" width="560" height="315" frameborder="0"></iframe>
La primera generación de bases de datos utilizaba modelos jerárquicos o modelos en red. El núcleo de los primeros es una estructura en forma de árbol en la que cada registro tiene un solo propietario. Podéis ver cómo funciona utilizando el ejemplo de InterSystems IRIS, porque su modelo principal es jerárquico y todos los datos se almacenan en globals (que son árboles B). Podéis leer más sobre los globals aquí.
Podemos crear este árbol en IRIS:
Set^a("+7926X", "city") = "Moscow"Set^a("+7926X", "city", "street") = "Req Square"Set^a("+7926X", "age") = 25Set^a("+7916Y", "city") = "London"Set^a("+7916Y", "city", "street") = "Baker Street"Set^a("+7916Y", "age") = 36Y verlo en la base de datos:
Después, Edgar F. Codd propuso su álgebra relacional y su teoría del almacenamiento de datos, basada en principios relacionales, en 1969. Y tras ello se crearon las bases de datos relacionales. El uso de relaciones (tablas), atributos (columnas), tuplas (filas) y, lo que es más importante, transacciones y requisitos ACID, hizo que estas bases de datos fueran muy populares y lo siguen siendo ahora.
Por ejemplo, tenemos el siguiente esquema:
Podemos crear y completar tablas:
Y si escribimos la consulta:
select p.ID, p.Name, a.Country, A.City
from My.Person p left join My.Address a
on p.Address = a.IDrecibiremos la respuesta:
A pesar de las significativas ventajas de las bases de datos relacionales, con la difusión de los lenguajes de objetos se hizo necesario almacenar datos orientados a objetos en bases de datos. Por eso, en los años 90 aparecieron las primeras bases de datos orientadas a objetos y objeto-relacionales. Estas últimas se crearon a partir de bases de datos relacionales y añadiéndole complementos para simular el trabajo con objetos. Las primeras se desarrollaron desde cero a partir de las recomendaciones del consorcio OMG (Object Management Group) y después del ODMG (Object Data Management Group).
Las ideas clave de estas bases de datos orientadas a objetos son las siguientes.
El almacén de datos único es accesible usando:
Este modelo permite obtener datos de bases de datos mediante lenguajes orientados a objetos.
Si tomamos la misma estructura que en el ejemplo anterior, pero en la forma orientada a objetos, tendremos las siguientes clases:
Class My.Person Extends%Persistent
{
Property Name As%Name;Property Address As My.Address;
}Class My.Address Extends%Persistent
{
Property Country;Property City;
}Y podemos crear los objetos utilizando el lenguaje orientado a objetos:
set address = ##class(My.Address).%New()
set address.Country = "France"
set address.City = "Marseille"
do address.%Save()
set person = ##class(My.Person).%New()
set person.Address = address
set person.Name = "Quouinaut, Martin"
do person.%Save()Desafortunadamente, las bases de datos de objetos no lograron competir con las bases de datos relacionales a pesar de su posición dominante, y como resultado, surgieron muchos ORM.
En cualquier caso, con la expansión de Internet en la década de los 2000 y la aparición de nuevos requisitos para el almacenamiento de datos, empezaron a surgir otros modelos de datos y DBMS. Dos de estos modelos que se utilizan en IRIS son los de documentos y columnas.
Las bases de datos orientadas a documentos se utilizan para gestionar datos semiestructurados. Se trata de datos que no siguen una estructura fija y llevan la estructura dentro. Cada unidad de información en una base de datos de este tipo es un par simple: una clave y un documento específico. Este documento normalmente tiene un formato JSON y contiene la información. Como la base de datos no requiere un esquema particular, también es posible integrar distintos tipos de documentos en el mismo almacén.
Si tomamos el ejemplo anterior, podemos tener documentos como estos:
{
"Name":"Quouinaut, Martin",
"Address":{
"Country":"France",
"City":"Paris"
}
}
{
"Name":"Merlingue, Luke",
"Address":{
"Country":"France",
"City":"Nancy"
},
"Age":26
}Estos dos documentos con un distinto número de campos se almacenan en la base de datos de IRIS sin ningún problema.
Y el último ejemplo de un modelo que estará disponible en la versión 2022.2 es el modelo de columnas. En este caso, el DBMS almacena las tablas de datos por columnas y no por filas.
La orientación por columnas permite un acceso más eficiente a los datos para consultar un subconjunto de columnas (eliminando la necesidad de leer columnas que no son relevantes), y más opciones para comprimir datos. Asimismo, comprimir por columnas es más eficaz cuando los datos de la columna son similares. No obstante, generalmente son menos eficaces para insertar nuevos datos.
Podéis crear esta tabla:
Create Table My.Address (
city varchar(50),
zip varchar(5),
country varchar(15)
) WITH STORAGETYPE = COLUMNAREn este caso, la clase es la siguiente:
Class My.Address Extends%Persistent [ ClassType = persistent, DdlAllowed, Final, Owner = {UnknownUser}, ProcedureBlock, SqlRowIdPrivate, SqlTableName = Address ]
{
Property city As%Library.String(COLLATION = "EXACT", MAXLEN = 50) [ SqlColumnNumber = 2 ];Property zip As%Library.String(COLLATION = "EXACT", MAXLEN = 5) [ SqlColumnNumber = 3 ];Property country As%Library.String(COLLATION = "EXACT", MAXLEN = 15) [ SqlColumnNumber = 4 ];Parameter STORAGEDEFAULT = "columnar";Parameter USEEXTENTSET = 1;/// Bitmap Extent Index auto-generated by DDL CREATE TABLE statement. Do not edit the SqlName of this index.
Index DDLBEIndex [ Extent, SqlName = "%%DDLBEIndex", Type = bitmap ];
Storage Default
{
<Data name="_CDM_city">
<Attribute>city</Attribute>
<ColumnarGlobal>^q3AW.DZLd.1.V1</ColumnarGlobal>
<Structure>vector</Structure>
</Data>
<Data name="_CDM_country">
<Attribute>country</Attribute>
<ColumnarGlobal>^q3AW.DZLd.1.V2</ColumnarGlobal>
<Structure>vector</Structure>
</Data>
<Data name="_CDM_zip">
<Attribute>zip</Attribute>
<ColumnarGlobal>^q3AW.DZLd.1.V3</ColumnarGlobal>
<Structure>vector</Structure>
</Data>
<DataLocation>^q3AW.DZLd.1</DataLocation>
<ExtentLocation>^q3AW.DZLd</ExtentLocation>
<ExtentSize>3</ExtentSize>
<IdFunction>sequence</IdFunction>
<IdLocation>^q3AW.DZLd.1</IdLocation>
<Index name="DDLBEIndex">
<Location>^q3AW.DZLd.2</Location>
</Index>
<Index name="IDKEY">
<Location>^q3AW.DZLd.1</Location>
</Index>
<IndexLocation>^q3AW.DZLd.I</IndexLocation>
<Property name="%%ID">
<AverageFieldSize>3</AverageFieldSize>
<Selectivity>1</Selectivity>
</Property>
<Property name="city">
<AverageFieldSize>7</AverageFieldSize>
<Selectivity>33.3333%</Selectivity>
</Property>
<Property name="country">
<AverageFieldSize>7</AverageFieldSize>
<Selectivity>33.3333%</Selectivity>
</Property>
<Property name="zip">
<AverageFieldSize>7</AverageFieldSize>
<Selectivity>33.3333%</Selectivity>
</Property>
<SQLMap name="%%DDLBEIndex">
<BlockCount>-4</BlockCount>
</SQLMap>
<SQLMap name="IDKEY">
<BlockCount>-4</BlockCount>
</SQLMap>
<SQLMap name="_CDM_city">
<BlockCount>-4</BlockCount>
</SQLMap>
<SQLMap name="_CDM_country">
<BlockCount>-4</BlockCount>
</SQLMap>
<SQLMap name="_CDM_zip">
<BlockCount>-4</BlockCount>
</SQLMap>
<StreamLocation>^q3AW.DZLd.S</StreamLocation>
<Type>%Storage.Persistent</Type>
}
}Después insertamos los datos:
insert into My.Address values ('London', '47000', 'UK')
insert into My.Address values ('Paris', '54000', 'France')
insert into My.Address values ('Kyiv', '03000', 'Ukraine')En los globals podemos ver:
Si abrimos el global con los nombres de las ciudades, podremos ver:
Y si escribimos una consulta:
select City
from My.Addressrecibimos los datos:
En este caso, el DBMS se limita únicamente a leer un global para obtener el resultado completo. Además, ahorra tiempo y recursos en la lectura.
Así pues, hemos hablado de 5 modelos de datos diferentes compatibles con la base de datos InterSystems IRIS: los modelos jerárquicos, relacionales, de objetos, de documentos y de columnas.
Espero que este artículo os resulte útil para saber qué modelos están disponibles. Si tenéis alguna pregunta, podéis escribirla en los comentarios.
De nuevo se me planteó un reto que me costó algún tiempo y muchas pruebas obtener la mejor solución. Y ahora que lo logré, me gustaría compartir mi nuevo conocimiento.
En un namespace hay muchas clases similares, así que para dejarlas más sencillas hay una superclase con las propiedades comunes. Además, entre las clases hay relaciones. Yo tenía que hacer una exportación de una de esas clases a JSON, pero no podía cambiar las superclases, porque si no, podría descomponer el flujo de otras integraciones.
Me gustaría compartir algunas funciones de almacenamiento que también existen en Caché y que son prácticamente desconocidas y en su mayoría no se utilizan. Por supuesto, están disponibles en IRIS y son más relevantes con arquitecturas de almacenamiento extensas y distribuidas.
En SQL, la condición más frecuente WHERE se relaciona principalmente con el contenido de las filas en las que trabajas.
Por lo tanto, debe calcularse y verificarse para cada fila a la que accedas.
Distinto es el caso (y por eso la llamé ESTÁTICA) de una condición WHERE independiente de las filas a las que accedes.
¡Hola a tod@s!
Cuando hablo con alguien de perfil técnico por primera vez acerca de InterSystems IRIS, siempre comienzo hablando de que en el centro de todo InterSystems IRIS es una Base de Datos Multimodelo. En mi opinión, esta es la mayor ventaja (desde la visión de Sistemas de Bases de Datos), ya que:
Y en todos los casos, el dato está almacenado de forma única. ¡Tú eliges la manera en la que quieres acceder al mismo!!
De un primer vistazo es una bonita historia - corta, concisa y con un mensaje; pero cuando se empieza a trabajar con InterSystems IRIS, comienzan a surgir preguntas: ¿Cómo están relacionados las clases, las tablas y los globals? ¿Qué son cada uno para el otro? ¿Cómo se almacenan realmente los datos?
En este artículo voy a tratar de responder estas preguntas y explicar qué está pasando realmente.
¡Hola Comunidad!
Os traemos el cuarto episodio de Data Points, el podcast de InterSystems en inglés. En esta ocasión, charlamos con @Benjamin De Boe, que nos explica algunas de las cosas que podéis hacer para optimizar vuestras consultas SQL en InterSystems IRIS.
Todos hemos oído — tanto de nosotros mismos como de otros — la queja "esto va demasiado lento". Creo que Benjamin ha hecho un gran trabajo revisando todas las cosas en las que os podeis fijar en vuestras consultas en IRIS para descubrir lo que se puede mejorar.
¡Hola a tod@s!
En las partes anteriores (1, 2) de este artículo, hablamos de Globals como árboles. En esta tercera parte, los veremos como matrices dispersas.
Una matriz dispersa es un tipo de matriz donde la mayoría de los valores asumen un valor idéntico.
En la práctica, a menudo veréis matrices dispersas tan grandes que no tiene sentido ocupar memoria con elementos idénticos. Por lo tanto, tiene sentido organizar matrices dispersas de tal manera que no se desperdicie memoria al almacenar valores duplicados.
En algunos lenguajes de programación, las matrices dispersas son parte del lenguaje (por ejemplo, en J, MATLAB). En otros lenguajes, hay bibliotecas especiales que permiten usarlas. Para C ++, esos serían Eigen y similares.
Los Globals son buenos candidatos para implementar matrices dispersas por las siguientes razones:
Principiantes- ver Parte 1.
Una estructura, como un árbol ordenado, tiene varios casos especiales. Echemos un vistazo a aquellos que tienen un valor práctico para trabajar con globals.
Los globals pueden usarse no solo como una matriz, sino como variables regulares. Por ejemplo, para crear un contador:
¡Hola a tod@s!
En este artículo voy a hablar sobre los Globals, esas espadas mágicas para almacenar datos, que han estado con nosotros desde hace tiempo, pero no mucha gente las utiliza de forma eficiente o realmente conoce esta súper herramienta.
Si se utilizan globals para realizar las tareas en donde realmente brillan, los resultados pueden ser sorprendentes, ya sea en términos de un mayor rendimiento o en una simplificación drástica de la solución en general (1, 2).
Globals ofrecen una forma especial de almacenar y procesar datos, la cual es completamente diferente de las tablas SQL. Se introdujeron por primera vez en 1966 con el lenguaje de programación M(UMPS), donde inicialmente se utilizaron en las bases de datos médicas. Todavía se usan de la misma manera, pero también fueron adoptados por otras industrias donde la confiabilidad y el alto rendimiento son la máxima prioridad (como en las finanzas, las operaciones comerciales, etc.)