Como (a) as informações com as quais você está trabalhando parecem ser, por si só, um recurso organizacional muito valioso e (b) o volume de dados é considerável, eu decididamente (c) constrói um banco de dados relacional em um dos as principais plataformas SQL.
Isso, é claro - de uma perspectiva muito geral - requer três fatores essenciais:
Um esquema conceitual claramente definido , no qual é necessário identificar e marcar com precisão os protótipos das coisas, ou seja, os tipos de entidade (incluindo suas propriedades e inter - relações ) de relevância no ambiente de negócios com o qual você está trabalhando (por exemplo, as Torres e Sensores mencionados).
Como você sabe, esse ponto implica estabelecer uma comunicação contínua e produtiva com especialistas em negócios.
Um layout lógico que reflete o nível conceitual com precisão, por meio de tabelas (relações matemáticas) que contêm colunas bem delimitadas com nomes e tipos de colunas apropriados (atributos da relação) e todas as restrições correspondentes para garantir que os dados estejam em conformidade com todas as regras determinadas no nível anterior.
Portanto, é aqui que entra em jogo o vasto poder do modelo relacional (embora suas vantagens tenham repercussões positivas em outros níveis de abstração).
Um arranjo físico que, por exemplo, aumenta a velocidade de execução das operações de manipulação de dados lógicos - dinâmicos - e garante as restrições lógicas.
Como o modelo relacional oferece independência de dados físicos , um sistema de gerenciamento de banco de dados (DBMS por brevidade) pode fornecer qualquer tipo de estrutura nesse nível, e não exclusivamente índices, para suportar as definições lógicas. No caso das principais plataformas SQL, sim, isso geralmente implica, precisamente, a configuração de uma estratégia de indexação com base nas tendências de consulta específicas do banco de dados, e você trouxe considerações muito interessantes em relação a algumas configurações possíveis, mas sem conhecer as particularidades. informações com precisão, oferecer conselhos específicos a esse respeito não seria adequado.
Outros elementos que merecem avaliação são, por exemplo, a atualização da infraestrutura de rede para aumentar a largura de banda, permitindo configurações adequadas de servidor (em termos de hardware e software), etc. E, se, e somente se, um profissional for qualificado o suficiente, ele poderá modifique o código fonte do DBMS de sua escolha (mais viável em ambientes de código aberto, naturalmente).
Dessa forma, os seguintes aspectos que você destaca
- Gerencie e recupere configurações de torre / sensor para entender a análise de dados.
- Visualização de dados por sensor ou intervalos de tempo para observações meteorológicas.
- Forneça aos clientes recursos / conjuntos de dados confiáveis e persistentes para comparar o desempenho do modelo e do sensor (pode ser necessário algum pós-processamento para ser entregue no formato necessário?).
seria bem endereçado, porque você poderia facilmente declarar consultas para, por exemplo, obter informações de formas muito significativas. Por exemplo, você pode obter dados associados a
- o Sensor identificado pelo SensorNumber
1750, instalado na Torre identificado pelo TowerNumber 31, entre a Data 1 June 2017e a Data27 June 2017 .
Além disso, como (1) os dados em um banco de dados relacional são gerenciados logicamente em termos de conjuntos, com o auxílio de operações baseadas na álgebra relacional , e (2) os diferentes mecanismos SQL são fisicamente otimizados (alguns mais que os outros) para o conjunto processamento , você pode, por exemplo,
- compare o conjunto a com o conjunto b ;
- junte o conjunto c com o conjunto d ;
- obter sub conjunto f através de uma restrição em conjunto e ;
- produzir n subconjuntos a partir de n conjuntos de interseções;
- atributos do projeto n do conjunto f
- recuperar informações do conjunto z que é o resultado de uma união do conjunto x com o conjunto y ;
- e assim por diante.
As possibilidades de manipulação de dados são enormes - demonstrando a versatilidade incomparável do paradigma relacional - já que você pode trabalhar não apenas com tabelas de base (as declaradas com CREATE TABLE … ( … );instruções), mas também com as derivadas (as expressas por meio de SELECT …;operações, às vezes fixadas como VIEWs) . Em outras palavras, você pode (i) expressar novas estruturas de dados com base em (ii) anteriores, operando em (iii) o único construto relacional subjacente, ou seja, a relação matemática.
Evidentemente, o arranjo das tabelas e colunas base de um banco de dados relacional pode evoluir e (a) novas tabelas ou colunas base podem ser incorporadas a ele quando (b) manter o controle de novos tipos de entidade ou propriedades de tipo de entidade é considerado útil no contexto de negócios pertinente. Em outras palavras, nem a estrutura inicial nem as restrições de abertura de um banco de dados relacional devem ser estáticas ou imutáveis. Além disso, um banco de dados organizado adequadamente desde o início tende a ser muito mais fácil de modificar quando surgem novos requisitos de informação.
De acordo com as considerações acima, o formato lógico dos conjuntos aplicáveis deve ser produzido declarativamente , no nível lógico do banco de dados. A formatação gráfica ou de apresentação dos conjuntos (por exemplo, as faces de coloração ou fonte utilizadas) deve, por sua vez, ser processada por meio do código de um ou mais programas aplicativos (sim, principalmente de maneira processual , talvez com a ajuda de um objeto orientada a objetos, HTML, etc.), para facilitar o acesso e a apresentação de tais conjuntos. Certamente, você também pode usar o software de relatório que se conecta ao seu banco de dados.
A modelagem de um banco de dados de relevância
Como você trabalhará com os dados do sensor (que, entre outros recursos, geralmente envolvem informações na forma de séries temporais ), você pode encontrar ajuda para o design de vários bancos de dados e os princípios gerais de administração contidos nas duas respostas excepcionais do @PerformanceDBA , às perguntas intituladas:
As abordagens Relational, Flat File e NoSQL
O modelo relacional do Dr. Edgar Frank Codd , embora publicado em 1970, permanece genuinamente o método mais moderno e elegante (baseado na lógica e na teoria dos conjuntos) para lidar com o problema do gerenciamento de dados. Os DBMSs distintos do SQL são, por sua vez, as aproximações mais populares (que, embora não sejam totalmente compatíveis, são realmente poderosas) aos sistemas propostos na teoria relacional, e algumas delas foram fortemente otimizadas (por exemplo, no que diz respeito à mecanismos de nível) por décadas até agora. Além disso, é claro que as principais plataformas SQL podem (e serão capazes de) trabalhar com as tecnologias mais atualizadas de armazenamento (por exemplo, discos rígidos) e processamento (por exemplo, CPUs) com bastante eficiência.
Quando construído em um DBMS poderoso, um banco de dados relacional projetado adequadamente nos níveis conceitual, lógico e físico se tornaria decididamente um ativo independente, autodescritivo e autoprotetor que (1) é confiável e (2) oferece um resposta rápida, dois aspectos que, como você sabe, são de grande importância.
Arquivos simples
Portanto, a alegação a seguir
Disseram-me que a lógica para o uso de arquivos simples é que eles acreditavam que um banco de dados relacional exigiria muita sobrecarga.
é descartado facilmente, porque a abordagem de arquivo simples seria:
- pré-científico;
- longe de ser ideal para grandes volumes de dados;
- muito pesado;
- dependente do programa de aplicativo (e você teria que implementar manualmente a maioria dos recursos que os DBMSs adequados oferecem nativamente);
- seu desempenho será facilmente prejudicado;
- etc.
Considerando que - muito mais conveniente - moda relacional, para dizer o mínimo:
- ofereceria grande escalabilidade (é independente do nível físico, para que você possa aprimorar os mecanismos físicos subjacentes, conforme necessário);
- traria um estilo simples para manipular os dados (via operações abstratas ) e
- poderia trabalhar com vários programas de aplicativos simultaneamente (por exemplo, um ou mais aplicativos móveis e / ou um ou mais aplicativos da web e / ou um ou mais aplicativos da área de trabalho etc.).
Se, no entanto, você optar por utilizar arquivos simples, avalie o emprego de um utilitário robusto como o Awk que, embora não seja um DBMS (e não tenha sido projetado como tal), forneça recursos úteis para lidar com arquivos , registros , campos etc. Consulte o Guia do Usuário do GNU Awk para obter mais informações sobre este assunto.
NoSQL
"Dados não estruturados" e termos associados
De acordo com sua propaganda, a justificativa inicial para o uso dos DBMSs NoSQL é que eles devem ser usados em domínios de negócios que envolvem o manuseio de "dados não estruturados", o que faz a pergunta:
- Qual é o significado da expressão "dados não estruturados"?
A esse respeito, deve-se dizer que os dados, por sua própria natureza, são estruturados; se não tivesse estrutura, seria algo sem sentido; consequentemente, tal coisa (i) não poderia ser considerada um dado e (ii) não valeria a pena administrar. Portanto, "dados não estruturados" são uma expressão contraditória e infeliz.
Outra frase desses contextos é "dados semiestruturados". Essa frase sugere que existem dados estruturados "em parte" ou "pela metade". Portanto, de acordo com o parágrafo anterior, apenas a "parte" ou a "metade" estruturada podem ser dados reais, a restante "parte" ou "metade" é apenas uma coisa sem forma, porque carece de estrutura e não pode ser chamado de dados.
Ainda outro, infelizmente, termo típico encontrado no marketing NoSQL é "dados polimórficos". Se o referido termo significa algo como "dados que têm muitas formas diferentes", então são de fato dados comuns , eles aparecem de várias formas distintas, como sempre. E, como possui muitas formas diferentes, apresenta muitas estruturas distintas ; portanto, não há nada de especial nesse "tipo" de dados.
Escusado será dizer que os dados e as estruturas de dados sempre foram suscetíveis a mudanças , então também não há nada incomum.
Crescimento do volume de dados
Evidentemente, o volume de informações gerenciadas por meio de sistemas computadorizados aumentou definitivamente ao longo dos anos - e continuará crescendo exponencialmente com o passar do tempo, porque novos sistemas estão sendo construídos todos os dias -, mas isso é um fato que não tem a ver com a estrutura da informação em si .
Falta de fundamentação teórica arredondada
Uma limitação crítica dos sistemas NoSQL (existem classes diferentes, por exemplo, com base em documentos e gráficos ) é que nenhum dos produtos atuais - embora seja amplamente comercializado e rotulado como "moderno" - possui uma sólida base teórica (se houver) que suporta todos e cada um dos três elementos mais importantes de um DBMS adequado, ou seja, ferramentas para definição de dados (a), (b) manipulação e (c) constrição. Assim, a abordagem NoSQL, na verdade, sugere uma regressão a uma era antiga, na qual o tratamento dos dados era realizado em um curso de ação ad hoc e doentio, com toda a complexidade desnecessária que isso implica.
Atualmente, os sistemas gráficos estão incluídos no espectro "NoSQL". Esses produtos de software convidam a gerenciar dados em virtude de operações em duas estruturas distintas: nós e relacionamentos - que, mais uma vez, estão em conflito com o termo "dados não estruturados" - e se destacam no grupo "NoSQL" porque fazem isso. tem uma base matemática. No entanto, os produtos gráficos são bastante semelhantes às plataformas de rede , consideradas obsoletas há dezenas de anos (uma desvantagem óbvia é que, conforme sugerido acima, eles precisam de duas estruturas para representação de dados, enquanto um DBMS relacional - conforme o princípio da informação - precisa de apenas um).
Mesmo que a criação dos diferentes sistemas NoSQL seja cronologicamente mais recente em comparação com as origens da maioria dos DBMSs SQL, a maioria dos conceitos nos quais os produtos NoSQL se baseiam são, na verdade, primitivos .
Um programa NoSQL deve ser empregado, principalmente, em cenários onde, por exemplo,
- o pessoal de TI não possui as habilidades técnicas necessárias para determinar (ou determinar oportunamente) a estrutura dos dados de interesse - ou seja, devido à sua complexidade -; e / ou
- a organização não pode oferecer educação e treinamento adequados para a equipe atual ou não pode contratar novos funcionários que possuam a educação e o treinamento necessários; e / ou
- quando a integridade e consistência dos dados não são particularmente importantes; e / ou
- ao misturar os dados preocupantes com os dos sistemas de missão crítica que exigem alta precisão não é esperado.
Mas, mesmo que a estrutura dos dados em questão não seja definida antes da criação dos sistemas em questão, uma ou mais pessoas terão necessariamente que
- descobrir a estrutura acima mencionada,
- descartar toda a “interferência” ao redor e
- coletar e vincular os dados adequados
após o banco de dados e os aplicativos terem entrado no estágio de produção, a fim de obter o máximo de todos os recursos investidos em um projeto, o delineamento da estrutura de dados é uma tarefa que não pode ser contornada; isso deve ser feito mais cedo ou mais tarde.
Portanto, enquanto seguir o caminho do NoSQL é uma possibilidade, todos os fatores mencionados anteriormente devem definitivamente ser levados em consideração.
O método mais robusto
Por outro lado, abordar os requisitos de informação de um ambiente de negócios de maneira relacional - ou seja, com um paradigma geral por trás - oferece as possibilidades de (1) gerenciar os dados em sua estrutura natural desde o início - o que facilita a integração com outras fontes de dados - e também de (2) produzir novas estruturas confiáveis devido à manipulação de um único instrumento - como explicado nas seções anteriores - que possui uma sólida base científica.
De acordo com sua descrição do cenário em questão, você já identificou uma estrutura específica em termos das necessidades organizacionais relevantes, por isso sugiro solicitar que os especialistas do domínio comercial a validem. Sucessivamente, recomendo tirar proveito de (i) os constructos - a relação, os constrangimentos e as operações - fornecidos pelo modelo relacional para lidar com a estrutura e os dados respectivos e (ii) com o DBMS SQL de sua escolha, o que provavelmente oferecem ferramentas físicas muito eficientes que podem suportar as demandas atuais e fornecerão escalabilidade futura.