Dado que (a) la información con la que está trabajando parece ser, en sí misma, un recurso organizacional muy valioso, y (b) el volumen de datos será considerable, decididamente (c) construiría una base de datos relacional en uno de Las principales plataformas SQL.
Eso, por supuesto, desde una perspectiva muy general, requiere tres factores esenciales:
Un esquema conceptual claramente definido , en el que uno tiene que identificar y marcar con precisión los prototipos de cosas, es decir, los tipos de entidad (incluidas sus propiedades e interrelaciones ) de relevancia en el entorno empresarial con el que está trabajando (por ejemplo, las Torres y Sensores que mencionas).
Como saben, este punto implica establecer una comunicación continua y productiva con expertos en negocios.
Un diseño lógico que refleja el nivel conceptual con precisión, mediante tablas (es decir, relaciones matemáticas) que contienen columnas bien delimitadas con nombres y tipos de columna apropiados (es decir, atributos de relación) y todas las restricciones correspondientes para garantizar que los datos cumplan con todas las reglas determinadas en el nivel anterior.
Por lo tanto, es aquí donde entra en juego el vasto poder del modelo relacional (aunque sus ventajas tienen repercusiones positivas en otros niveles de abstracción).
Una disposición física que, por ejemplo, aumenta la velocidad de ejecución de las operaciones de manipulación de datos lógicos "dinámicos" y garantiza las restricciones lógicas.
Dado que el modelo relacional ofrece independencia de datos físicos , un sistema de gestión de bases de datos (DBMS por brevedad) puede proporcionar cualquier tipo de estructura a este nivel, no exclusivamente índices, para admitir las definiciones lógicas. En el caso de las principales plataformas SQL, sí, esto comúnmente implica, precisamente, establecer una estrategia de indexación basada en las tendencias de consulta específicas de la base de datos, y trajiste consideraciones muy interesantes con respecto a algunas configuraciones posibles pero, sin conocer el particular necesidades informativas con exactitud, ofrecer consejos específicos a este respecto no sería adecuado.
Otros elementos que merecen una evaluación son, por ejemplo, actualizar la infraestructura de red para aumentar el ancho de banda, permitir configuraciones de servidor adecuadas (en cuanto a hardware y software), etc. Y, si, y solo si, un profesional está suficientemente calificado, él o ella podrían incluso modificar el código fuente del DBMS de elección (más factible en entornos de código abierto, naturalmente).
De esta manera, los siguientes aspectos que destaca
- Administre y recupere configuraciones de torre / sensor para dar sentido al análisis de datos.
- Visualización de datos por sensor o intervalos de tiempo para observaciones meteorológicas.
- Proporcione a los clientes recursos de datos / conjuntos de datos confiables y persistentes para comparar el rendimiento del modelo y el sensor (¿puede requerir algún procesamiento posterior para entregar en el formato requerido?).
estaría bien direccionado, porque fácilmente podría declarar consultas para, por ejemplo, obtener información en formas muy significativas. Por ejemplo, puede obtener datos asociados con
- el Sensor identificado por SensorNumber
1750, instalado en la Torre identificada por TowerNumber 31, entre la Fecha 1 June 2017y la Fecha27 June 2017 .
Además, dado que (1) los datos en una base de datos relacional se gestionan lógicamente en términos de conjuntos con la ayuda de operaciones basadas en el álgebra relacional , y (2) los diferentes motores SQL están físicamente optimizados (algunos más que otros) para el conjunto procesamiento , puede, por ejemplo,
- compare el conjunto a con el conjunto b ;
- unir el conjunto c con el conjunto d ;
- obtener sub conjunto f a través de una restricción en el set e ;
- producir n subconjuntos de n intersecciones establecidas;
- proyectar n atributos del conjunto f
- recuperar información del conjunto z que es el resultado de una unión del conjunto x con el conjunto y ;
- y así.
De hecho, las posibilidades de manipulación de datos son enormes, lo que demuestra la versatilidad incomparable del paradigma relacional, ya que puede trabajar no solo con tablas base (las declaradas con CREATE TABLE … ( … );declaraciones) sino también con las derivadas (las expresadas a través de SELECT …;operaciones, a veces fijadas como VIEWs) . En otras palabras, puede (i) expresar nuevas estructuras de datos basadas en (ii) las anteriores que operan en (iii) la construcción relacional subyacente única, es decir, la relación matemática.
Evidentemente, la disposición de las tablas y columnas base de una base de datos relacional puede evolucionar y (a) se pueden incorporar nuevas tablas o columnas base cuando (b) se considera que vale la pena realizar un seguimiento de los nuevos tipos de entidad o propiedades de tipo de entidad. contexto comercial pertinente. En otras palabras, ni la estructura inicial ni las restricciones de apertura de una base de datos relacional se espera que sean estáticas o inmutables. Además, una base de datos que se organiza adecuadamente desde el principio tiende a ser mucho más fácil de modificar cuando surgen nuevos requisitos de información.
De acuerdo con las consideraciones anteriores, el formato lógico de los conjuntos aplicables debe producirse de forma declarativa , a nivel lógico de la base de datos. El formato gráfico o de presentación de los conjuntos (p. Ej., Los colores o las caras de las fuentes utilizadas) a su vez debe procesarse mediante el código de uno o más programas de aplicación (sí, principalmente de manera procesal , quizás con la ayuda de un objeto -orientado, HTML, etc.), para que el acceso y la presentación de dichos conjuntos sean fáciles de usar. Ciertamente, también podría utilizar el software de informes que se conecta con su base de datos.
El modelado de una base de datos de relevancia.
Dado que trabajará con los datos del Sensor (que, entre otras características, generalmente incluye información en forma de series de tiempo ), puede encontrar ayuda para el diseño de múltiples bases de datos y principios generales de administración contenidos en las dos respuestas excepcionales, por @PerformanceDBA , a las preguntas tituladas:
Los enfoques relacionales, de archivo plano y NoSQL
El modelo relacional del Dr. Edgar Frank Codd , aunque publicado en 1970, sigue siendo el método más moderno y elegante (basado en la lógica y la teoría de conjuntos) para hacer frente al problema de la gestión de datos. Los distintos DBMS de SQL son, a su vez, las aproximaciones más populares (que, aunque no son totalmente compatibles, sin embargo, son realmente potentes) a los sistemas propuestos en la teoría relacional, y algunos de ellos han sido muy optimizados (por ejemplo, con respecto a su aspecto físico). mecanismos de nivel) desde hace incluso décadas. Además, las principales plataformas SQL, por supuesto, pueden (y podrán) trabajar con las tecnologías más actualizadas de almacenamiento (por ejemplo, discos duros) y procesamiento (por ejemplo, CPU) de manera bastante eficiente.
Cuando se construye sobre un poderoso DBMS, una base de datos relacional que está diseñada adecuadamente en los niveles conceptual, lógico y físico se convertiría decididamente en un activo autónomo, autodescriptivo y protector que (1) es confiable y (2) ofrece un Respuesta rápida, dos aspectos que, como saben, son de gran importancia.
Archivos planos
Por lo tanto, la afirmación que sigue
Me dijeron que la razón para usar archivos planos es que creían que una base de datos relacional tomaría demasiada sobrecarga.
se descarta fácilmente, porque el enfoque de archivo plano sería:
- pre-científico;
- lejos de ser óptimo para grandes volúmenes de datos;
- demasiado engorroso
- depende del programa de aplicación (y tendría que implementar manualmente la mayoría de las características que los DBMS adecuados ofrecen de forma nativa);
- su rendimiento será socavado fácilmente;
- etc.
Mientras que la moda relacional —mucho más conveniente—, por decir lo menos:
- ofrecería una gran escalabilidad (es independiente del nivel físico, por lo que podría mejorar los mecanismos físicos subyacentes según sea necesario);
- traería un estilo simple para manipular los datos (a través de operaciones abstractas ) y
- podría funcionar con múltiples programas de aplicaciones simultáneamente (por ejemplo, una o más aplicaciones móviles, y / o una o más aplicaciones web, y / o una o más aplicaciones de escritorio, etc.).
Sin embargo, si opta por utilizar archivos planos, debe evaluar el empleo de una utilidad sólida como Awk que, aunque no es un DBMS (y no fue diseñado como tal), proporciona recursos útiles para manejar archivos , registros , campos , etc. Consulte la Guía del usuario de GNU Awk para obtener más información sobre este tema.
NoSQL
"Datos no estructurados" y términos asociados
Según su propaganda, la justificación inicial para el uso de DBMS NoSQL es que están destinados a ser utilizados en dominios comerciales que implican el manejo de "datos no estructurados", por lo que se plantea la pregunta:
- ¿Qué se supone que significa la expresión "datos no estructurados"?
A ese respecto, debe decirse que los datos, por su propia naturaleza, están estructurados; si no tuviera estructura, entonces sería algo sin sentido, por lo tanto (i) no podría considerarse datos y (ii) no valdría la pena administrarlo. Por lo tanto, "datos no estructurados" es una expresión contradictoria y desafortunada.
Otra frase de esos contextos es "datos semiestructurados". Esa frase sugiere que existen datos que están estructurados "en parte" o "en la mitad", por lo que, de acuerdo con el párrafo anterior, solo la "parte" o "mitad" que está estructurada pueden ser datos reales, la "parte" restante o "mitad" es simplemente una cosa sin forma porque carece de estructura y no puede ser referida como datos.
Sin embargo, otro término típico que se encuentra en el marketing NoSQL es "datos polimórficos". Si dicho término significa algo así como "datos que tienen muchas formas diferentes", entonces, de hecho , son datos ordinarios , se presentan en muchas formas distintas como siempre. Y dado que tiene muchas formas diferentes, presenta muchas estructuras distintas , por lo que no hay nada especial en este "tipo" de datos.
Huelga decir que los datos y las estructuras de datos siempre han sido susceptibles a cambios , entonces tampoco hay nada inusual en este sentido.
Crecimiento del volumen de datos
Evidentemente, los volúmenes de información administrados por medio de sistemas computarizados definitivamente han crecido a lo largo de los años, y seguirán creciendo exponencialmente a medida que pasa el tiempo, porque se están construyendo nuevos sistemas todos los días, pero eso es un hecho que no tiene que ver con La estructura de la información per se .
Falta de una base teórica redondeada
Una limitación crítica de los sistemas NoSQL (hay de diferentes clases, por ejemplo, basadas en documentos y gráficos ) es que ninguno de los productos actuales, aunque comercializados y etiquetados como "modernos", posee una base teórica sólida (si es que existe) que admite todos y cada uno de los tres elementos más importantes de un DBMS adecuado, es decir, herramientas para la definición de datos (a), (b) manipulación y (c) constricción. Por lo tanto, el enfoque NoSQL en realidad sugiere una regresión a una era antigua en la que el manejo de los datos se realizó en un curso de acción ad hoc y poco sólido, con toda la complejidad innecesaria que conlleva.
Hoy en día, los sistemas de gráficos se incluyen dentro del espectro "NoSQL". Estos productos de software invitan a administrar datos en virtud de operaciones en dos estructuras distintas: nodos y relaciones , que, una vez más, están en conflicto con el término "datos no estructurados", y se destacan en el grupo "NoSQL" porque lo hacen tener una base matemática Sin embargo, los productos gráficos son bastante similares a las plataformas de red , que se consideran obsoletas desde hace decenas de años (un inconveniente obvio es que, como se sugirió anteriormente, necesitan dos estructuras para la representación de datos, mientras que un DBMS relacional, según el principio de información ) solo necesita uno).
Incluso si la creación de los diferentes sistemas NoSQL es cronológicamente más nueva en comparación con los orígenes de la mayoría de los DBMS de SQL, la mayoría de los conceptos en los que se basan los productos NoSQL son, en efecto, primitivos .
Un programa NoSQL debe emplearse, principalmente, en escenarios donde, por ejemplo,
- el personal de TI carece de las habilidades técnicas necesarias para determinar (o determinar oportunamente) la estructura de los datos de interés, por ejemplo, debido a su complejidad; y / o
- la organización no puede permitirse una educación y capacitación adecuadas para el personal actual, o no puede contratar personal nuevo que posea la educación y capacitación requeridas; y / o
- cuando la integridad y consistencia de los datos no es particularmente importante; y / o
- cuando se mezclan los datos relevantes con los de los sistemas de misión crítica que exigen alta precisión no se espera.
Pero, incluso si la estructura de los datos en cuestión no se define antes de la creación de los sistemas en cuestión, una o más personas necesariamente tendrán que
- descubrir la estructura mencionada,
- descartar toda la "interferencia" circundante y
- recopilar y vincular los datos adecuados
después de que la base de datos y las aplicaciones hayan entrado en la etapa de producción para poder aprovechar al máximo todos los recursos invertidos en un proyecto, entonces la delineación de la estructura de datos es una tarea que no se puede omitir, debe hacerse antes o después.
Entonces, si bien seguir el camino NoSQL es una posibilidad, todos los factores mencionados anteriormente definitivamente deben tenerse en cuenta.
El método más robusto.
Por el contrario, abordar los requisitos de información de un entorno empresarial de una manera relacional, es decir, con un paradigma general detrás, ofrece las posibilidades de (1) administrar los datos en su estructura natural desde el principio, lo que facilita la integración con otras fuentes de datos. y también de (2) producir nuevas estructuras confiables a fuerza de la manipulación de un solo instrumento, como se explicó en secciones anteriores, que tiene una sólida base científica.
De acuerdo con su descripción del escenario en cuestión, ya ha identificado una estructura particular en términos de las necesidades organizativas relevantes, por lo que le sugiero que solicite a los expertos del dominio empresarial que la validen. Sucesivamente, recomiendo aprovechar (i) las construcciones —la relación, las restricciones y las operaciones— proporcionadas por el modelo relacional para manejar dicha estructura y los datos respectivos, y de (ii) su SQL DBMS de elección que muy probablemente ofrece herramientas físicas muy eficientes que pueden soportar las demandas actuales y proporcionarán escalabilidad futura.
