Aula número 10. Formas normais

1. O significado da normalização do esquema de banco de dados

O conceito que consideraremos nesta seção está relacionado ao conceito de dependências funcionais, ou seja, o significado de normalizar esquemas de banco de dados está inextricavelmente ligado ao conceito de restrições impostas por um sistema de dependências funcionais, e em grande parte decorre desse conceito.

O ponto de partida de qualquer projeto de banco de dados é representar o domínio como um ou mais relacionamentos e, em cada etapa do projeto, algum conjunto de esquemas de relacionamento é produzido com propriedades "aprimoradas". Assim, o processo de projeto é um processo de normalização de padrões de relacionamento, com cada forma normal sucessiva tendo propriedades que são, em certo sentido, melhores que a anterior.

Cada forma normal tem um certo conjunto de restrições, e uma relação está em uma certa forma normal se ela satisfaz seu próprio conjunto de restrições. Um exemplo é a restrição da primeira forma normal - os valores de todos os atributos da relação são atômicos.

Na teoria de banco de dados relacional, a seguinte sequência de formas normais é geralmente distinguida:

1) primeira forma normal (1 NF);

2) segunda forma normal (2 NF);

3) terceira forma normal (3 FN);

4) forma normal de Boyce-Codd (BCNF);

5) quarta forma normal (4 NF);

6) quinta forma normal, ou forma normal de junção de projeção (5 NF ou PJ/NF).

(Este curso de palestras inclui uma discussão detalhada das quatro primeiras formas normais de relações básicas, portanto, não analisaremos a quarta e a quinta formas normais em detalhes.)

As principais propriedades das formas normais são as seguintes:

1) cada forma normal seguinte é, em certo sentido, melhor do que a forma normal anterior;

2) ao passar para a próxima forma normal, as propriedades das formas normais anteriores são preservadas.

O processo de projeto é baseado no método de normalização, ou seja, decomposição de uma relação que está na forma normal anterior em duas ou mais relações que satisfaçam os requisitos da próxima forma normal (encontraremos isso quando nós mesmos tivermos que normalizar aquela à medida que passamos pelo material) ou alguma outra relação básica).

Conforme mencionado na seção sobre como criar relacionamentos básicos, os conjuntos fornecidos de dependências funcionais impõem restrições apropriadas aos esquemas de relacionamentos básicos. Essas restrições geralmente são implementadas de duas maneiras:

1) declarativamente, ou seja, declarando vários tipos de chaves primárias, candidatas e estrangeiras na relação base (este é o método mais utilizado);

2) processualmente, ou seja, escrever o código do programa (usando os chamados gatilhos mencionados acima).

Com a ajuda de uma lógica simples, você pode entender qual é o objetivo de normalizar esquemas de banco de dados. Normalizar bancos de dados ou trazer bancos de dados para uma forma normal significa definir tais esquemas de relações básicas para minimizar a necessidade de escrever código de programa, aumentar o desempenho do banco de dados e facilitar a manutenção da integridade dos dados por estado e integridade referencial. Ou seja, tornar o código e trabalhar com ele o mais simples e conveniente possível para desenvolvedores e usuários.

Para demonstrar visualmente em comparação a operação de um banco de dados não normalizado e normalizado, considere o exemplo a seguir.

Vamos ter uma relação de base contendo informações sobre os resultados da sessão de exame. Já consideramos esse banco de dados antes.

Assim, 1 opção esquemas de banco de dados.

Sessão (número do livro de registro, Nome completo, Assunto, Avaliar)

Nesta relação, como você pode ver na imagem do esquema da relação base, uma chave primária composta é definida:

Chave primária (número da apostila, assunto);

Também a este respeito, é definido um sistema de dependências funcionais:

{Número do livro de contas} → {Sobrenome, Nome, Patronímico};

Aqui está uma visão tabular de um pequeno fragmento de um banco de dados com este esquema de relação. Já usamos este fragmento ao considerar as limitações das dependências funcionais, então será bem fácil entendermos este tópico usando seu exemplo.

Aqui, para manter a integridade dos dados por estado, ou seja, para cumprir a restrição do sistema de dependência funcional {classbook number} → {Last name, First name, Patronímico} ao alterar, por exemplo, o sobrenome, é necessário examinar todas as tuplas dessa relação básica e inserir sequencialmente as mudanças necessárias. No entanto, por se tratar de um processo bastante trabalhoso e demorado (principalmente se estivermos lidando com um banco de dados de uma grande instituição de ensino), os desenvolvedores de sistemas gerenciadores de banco de dados chegaram à conclusão de que esse processo precisa ser automatizado, ou seja, , automática. Agora, o controle sobre o cumprimento desta (e de qualquer outra) dependência funcional pode ser organizado automaticamente usando a declaração correta de várias chaves na relação base e a chamada decomposição (ou seja, quebrar algo em várias partes independentes) desta relação.

Então, vamos dividir nosso esquema de relacionamento "Sessão" existente em dois esquemas: o esquema "Alunos", que contém apenas informações sobre os alunos de uma determinada instituição de ensino, e o esquema "Sessão", que contém informações sobre a última sessão anterior. E então declararemos as chaves de forma que possamos obter facilmente qualquer informação necessária.

Vamos mostrar como serão esses novos esquemas de relacionamento com suas chaves.

opção 2 esquemas de banco de dados.

Alunos (número do livro de registro, Nome completo),

Chave primária (número do livro de notas).

Sessão (Número do livro de registro, Assunto, Avaliar),

Chave primária (número do livro de notas, Assunto),

Chave estrangeira (número do boletim de notas) referências Estudantes (número do boletim de notas).

O que nós temos agora? Em relação aos "Alunos", a chave primária "Número do boletim de notas" determina funcionalmente os outros três atributos: "Sobrenome", "Nome" e "Patronímico". E em relação a "Sessão", a chave primária composta "Nº do Boletim, Assunto" também de forma inequívoca, ou seja, define literalmente funcionalmente o último atributo desse esquema de relacionamento - "Pontuação". E a conexão entre essas duas relações foi estabelecida: é realizada através da chave externa da relação "Sessão" "Nº Caderno", que se refere ao atributo de mesmo nome na relação "Alunos" e, quando solicitado, fornece todas as informações necessárias.

Vamos agora mostrar como serão as relações representadas pelas tabelas correspondentes à segunda opção de especificar os esquemas de banco de dados correspondentes.

Assim, vemos que o objetivo da normalização em termos das restrições impostas pelas dependências funcionais é a necessidade de impor as dependências funcionais requeridas em qualquer banco de dados usando declarações de vários tipos de chaves primárias, candidatas e estrangeiras das relações de base.

2. Primeira Forma Normal (1NF)

Nos estágios iniciais de projeto de banco de dados e desenvolvimento de esquemas de gerenciamento de banco de dados, atributos simples e inequívocos foram usados ​​como as unidades de código mais produtivas e racionais. Em seguida, eles usaram atributos simples e compostos, bem como atributos de valor único e multivalorados. Vamos explicar o significado de cada um desses conceitos.

Atributos compostos, ao contrário dos simples, são atributos compostos por vários atributos simples.

Atributos multivalorados, ao contrário dos de valor único, são atributos que representam vários valores.

Aqui estão exemplos de atributos simples, compostos, de valor único e de vários valores.

Considere a tabela a seguir representando o relacionamento:

Aqui, o atributo "Telefone" é simples, inequívoco, e o atributo "Endereço" é simples, mas possui vários valores.

Agora considere outra tabela, com atributos diferentes:

Nesta relação, representada pela tabela, o atributo "Telefones" é simples, mas multivalorado, e o atributo "Endereços" é composto e multivalorado.

Em geral, várias combinações de atributos simples ou compostos são possíveis. Em casos diferentes, as tabelas que representam relacionamentos podem se parecer com isso em geral:

Ao normalizar esquemas de relações básicas, os programadores podem usar um dos quatro tipos mais comuns de formas normais: primeira forma normal (1NF), segunda forma normal (2NF), terceira forma normal (3NF) ou forma normal Boyce-Codd (NFBC). . Para esclarecer: a abreviação NF é uma abreviação da frase em inglês Normal Form. Formalmente, além das acima, existem outros tipos de formas normais, mas as acima são uma das mais populares.

Atualmente, os desenvolvedores de banco de dados estão tentando evitar atributos compostos e multivalorados para não complicar a escrita do código, não sobrecarregar sua estrutura e não confundir os usuários. A partir dessas considerações, a definição da primeira forma normal segue logicamente.

Definição. Qualquer relação de base está em primeira forma normal se e somente se o esquema dessa relação contém apenas atributos simples e de valor único, e necessariamente com a mesma semântica.

Para explicar visualmente as diferenças entre relações normalizadas e não normalizadas, considere um exemplo.

Seja, existe uma relação não normalizada, com o seguinte esquema.

Assim, 1 opção esquemas de relação com uma chave primária simples definida nele:

Funcionários (número pessoal, Sobrenome, Nome, Patronímico, Código do cargo, Telefones, Data de admissão ou demissão);

Chave primária (número pessoal);

Vamos listar quais erros existem nesse esquema de relacionamento, ou seja, nomearemos aqueles sinais que tornam esse esquema propriamente não normalizado:

1) o atributo "Sobrenome Nome Patronímico" é composto, ou seja, composto por elementos heterogêneos;

2) o atributo "Telefones" é multivalorado, ou seja, seu valor é um conjunto de valores;

3) o atributo "Data de aceitação ou demissão" não possui semântica inequívoca, ou seja, neste último caso não fica claro qual data é inserida.

Se, por exemplo, um atributo adicional for introduzido para definir com mais precisão o significado de uma data, o valor desse atributo será semanticamente claro, mas ainda assim será possível armazenar apenas uma das datas especificadas para cada funcionário.

O que precisa ser feito para trazer essa relação à forma normal?

Primeiro, é necessário dividir os atributos compostos em simples para excluir esses atributos muito compostos, bem como os atributos com semântica composta.

E em segundo lugar, é necessário decompor essa relação, ou seja, é necessário quebrá-la em várias novas relações independentes para excluir atributos multivalorados.

Assim, levando em conta todo o exposto, após reduzir a relação "Employees" para a primeira forma normal ou 1NF decompondo-a, obteremos um sistema das seguintes relações com chaves primárias e estrangeiras definidas sobre elas.

Assim, 2 opção relações:

Funcionários (número pessoal, Apelido, Nome próprio, Patronímico, Código do cargo, Data de admissão, Data de demissão);

Chave primária (número pessoal);

Telefones (Número pessoal, telefone);

Chave primária (número pessoal, telefone);

Referências de chave estrangeira (número pessoal) Funcionários (número pessoal);

Então o que vemos? O atributo composto "Sobrenome Nome Patronímico" não está mais em nossa relação, em vez dele existem três atributos simples "Sobrenome", "Nome" e "Patronímico", portanto, esse motivo da "anormalidade" do relacionamento foi excluído .

Além disso, em vez do atributo com semântica pouco clara "Data de contratação ou demissão", agora temos dois atributos "Data de admissão" e "Data de demissão", cada um com semântica inequívoca. Portanto, a segunda razão pela qual nossa relação "Empregados" não está na forma normal também é eliminada com segurança.

E, por fim, o último motivo pelo qual a relação "Empregados" não foi normalizada é a presença do atributo multivalorado "Telefones". Para se livrar desse atributo, foi necessário decompor todo o relacionamento. Como resultado dessa decomposição, o atributo "Telefones" foi excluído da relação original "Funcionários" em geral, mas formou-se uma segunda relação - "Telefones", na qual existem dois atributos: "número pessoal do funcionário" e "Telefone ", ou seja, todos os atributos - novamente simples, a condição de pertencer à primeira forma normal é satisfeita. Esses atributos "Número do funcionário" e "Telefone" formam uma chave primária composta da relação "Telefones", e o atributo "Número do funcionário", por sua vez, é uma chave estrangeira que se refere ao atributo de mesmo nome na lista "Funcionários". relação ", ou seja, em relação ao atributo "Telefones" da chave primária "número pessoal" é também uma chave estrangeira referente à chave primária da relação "Funcionários". Assim, um link é fornecido entre os dois relacionamentos. Usando este link, você pode exibir toda a lista de seus telefones pelo número pessoal de qualquer funcionário sem muito esforço e tempo sem recorrer ao uso de atributos compostos.

Observe que se houvesse dependências funcionais em relação ao sistema, após todas as transformações acima, a normalização não seria concluída. No entanto, neste exemplo específico, não há restrições de dependência funcional, portanto, não é necessária uma normalização adicional desse relacionamento.

3. Segunda Forma Normal (2NF)

Requisitos mais fortes são impostos às relações pela segunda forma normal, ou 2FN.

Isso porque a definição da segunda forma normal de relações implica, ao contrário da primeira forma normal, a presença de um sistema de restrições às dependências funcionais.

Definição. A relação de base está em segunda forma normal em relação a um determinado conjunto de dependências funcionais se e somente se ele estiver na primeira forma normal e, além disso, cada atributo não-chave for totalmente funcionalmente dependente de cada chave.

Nesta definição atributo não chave é qualquer atributo de relação que não esteja contido em nenhuma chave primária ou candidata da relação.

A dependência funcional total em uma chave não implica em nenhuma dependência funcional em qualquer parte dessa chave.

Assim, agora, ao normalizar uma relação, devemos também monitorar o atendimento das condições para que a relação esteja na primeira forma normal, ou seja, garantir que seus atributos sejam simples e inequívocos, bem como o atendimento da segunda condição quanto à as restrições de dependências funcionais.

É claro que as relações com chaves simples (primária e candidata) estão certamente na segunda forma normal. De fato, neste caso, a dependência de uma parte da chave simplesmente não parece possível, porque a chave simplesmente não tem partes separadas.

Agora, como na passagem do tópico anterior, considere um exemplo de um esquema de relação não normalizado e o próprio processo de normalização.

Assim, 1 opção esquemas de relação:

Públicos-alvo (Edifício nº, Auditório nº., Área m² m, No. comandante de serviço do corpo);

Chave primária (número do corpus, número da audiência);

Além disso, o seguinte sistema de dependência funcional é definido:

{Nº do corpo} → {Nº do comandante de serviço do corpo};

O que vemos? Todas as condições para que esta relação "Público" permaneça na primeira forma normal estão reunidas, porque cada atributo desta relação é inequívoco e simples. Mas a condição de que cada elemento não-chave deve ser completamente funcionalmente dependente da chave não é satisfeita. Por quê? Sim, porque o atributo "Nº do estado-maior comandante do corpo" não depende funcionalmente da chave composta "Nº do corpo, nº da audiência", mas de uma parte desta chave, ou seja, do atributo "Nº do corpo". De fato, afinal, é o número do corpo que determina completamente qual comandante específico é designado a ele e, por sua vez, o número pessoal do comandante do corpo não pode depender de nenhum número de auditório.

Assim, a principal tarefa da nossa normalização passa a ser a de garantir que as chaves sejam distribuídas de tal forma que, em particular, o atributo "No.

Para conseguir isso, teremos que aplicar novamente, como no parágrafo anterior, a decomposição da relação. Então, o seguinte sistema de relações, que é 2 opção O relacionamento “Público” foi obtido apenas do relacionamento original, decompondo-o em vários novos relacionamentos independentes:

Corpo (Nº do casco, número do comandante de pessoal do corpo);

Chave primária (número do caso);

Públicos-alvo (Edifício nº, Auditório nº., Área m² m);

Chave primária (número do corpus, número da audiência);

Referências de chave estrangeira (número do caso) Casos (número do caso);

O que vemos agora? Com relação ao atributo não-chave "Corpus" "Número de pessoal do comandante do Corpo" depende totalmente funcionalmente da chave primária "Número do Corpo". Aqui a condição para encontrar a relação na segunda forma normal é totalmente satisfeita.

Agora vamos passar para a consideração da segunda relação - "Público". Com relação a "Público", o atributo de chave primária "Caso #" também é uma chave estrangeira que se refere à chave primária do relacionamento "Caso". A este respeito, o atributo não chave "Área mXNUMX" é completamente dependente de toda a chave primária composta "Edifício #, Auditório #" e não depende, nem pode depender de nenhuma de suas partes.

Assim, decompondo a relação original, chegamos à conclusão de que todas as condições da definição da segunda forma normal são plenamente satisfeitas.

Neste exemplo, todos os requisitos de dependência funcional são impostos pela declaração de chaves primárias (sem chaves candidatas aqui) e chaves estrangeiras. Portanto, nenhuma normalização adicional é necessária.

4. Terceira Forma Normal (3NF)

A próxima forma normal que veremos é a terceira forma normal (ou 3FN). Ao contrário da primeira forma normal, bem como da segunda forma normal, a terceira implica a atribuição de um sistema de dependências funcionais juntamente com a relação. Vamos formular quais propriedades uma relação deve ter para que seja reduzida à terceira forma normal.

Definição. A relação de base está em terceira forma normal com relação a um determinado conjunto de dependências funcionais se e somente se ele estiver na segunda forma normal e cada atributo não-chave for funcionalmente dependente apenas de chaves.

Assim, os requisitos da terceira forma normal são mais fortes do que os requisitos da primeira e da segunda formas normais, mesmo combinadas. De fato, na terceira forma normal, todo atributo não chave depende da chave e da chave inteira, e de nada mais que a chave.

Vamos ilustrar o processo de trazer uma relação não normalizada para a terceira forma normal. Para fazer isso, considere um exemplo: uma relação que não está na terceira forma normal.

Assim, 1 opção esquemas da relação "Funcionários":

Funcionários (número pessoal, Sobrenome, Nome, Patronímico, Código Cargo, Salário);

Chave primária (número pessoal);

Além disso, o seguinte sistema de dependências funcionais é definido acima desse relacionamento "Funcionários":

{Código do cargo} → {Salário};

De fato, como regra, o valor do salário, ou seja, o valor dos salários, depende diretamente do cargo e, portanto, de seu código no banco de dados correspondente.

É por isso que esta relação "Funcionários" não está na terceira forma normal, porque acontece que o atributo não-chave "Salário" é completamente funcionalmente dependente do atributo "Código de cargo", embora este atributo não seja chave.

Curiosamente, qualquer relação se reduz à terceira forma normal exatamente da mesma maneira que às duas formas anteriores a esta, a saber, por decomposição.

Decompondo a relação "Empregados", obtemos o seguinte sistema de novas relações independentes:

Assim, 2 opção esquemas da relação "Funcionários":

Posições (Código de posição, Salário);

Chave primária (código de posição);

Funcionários (número pessoal, Sobrenome, Nome, Patronímico, Código do cargo);

Chave primária (código de posição);

Referências de chave estrangeira (código de posição) Posições (código de posição);

Agora, como podemos ver, em relação a "Cargo", o atributo não chave "Salário" é completamente funcionalmente dependente da chave primária simples "Código Cargo" e somente desta chave.

Observe que, em relação a "Funcionários", todos os quatro atributos não-chave "Sobrenome", "Nome", "Patronímico" e "Código de Cargo" são totalmente dependentes da chave primária simples "Número de Emprego". A este respeito, o atributo "Position ID" é uma chave estrangeira que se refere à chave primária do relacionamento "Positions".

Neste exemplo, todos os requisitos são impostos pela declaração de chaves primárias e estrangeiras simples, portanto, nenhuma normalização adicional é necessária.

É interessante e útil saber que, na prática, geralmente se limita a trazer os bancos de dados para a terceira forma normal. Ao mesmo tempo, algumas dependências funcionais de atributos-chave em outros atributos do mesmo relacionamento podem não ser impostas.

O suporte para essas dependências funcionais não padrão é implementado usando os gatilhos mencionados anteriormente (ou seja, processualmente, escrevendo o código de programa apropriado). Além disso, os gatilhos devem operar com tuplas dessa relação.

5. Forma Normal de Boyce-Codd (NFBC)

A forma normal de Boyce-Codd segue em "complexidade" logo após a terceira forma normal. Portanto, a forma normal de Boyce-Codd às vezes também é chamada simplesmente terceira forma normal forte (ou reforçado 3 NF). Por que ela é reforçada? Formulamos a definição da forma normal de Boyce-Codd:

Definição. A relação de base está em Boyce forma normal - Kodd se e somente se estiver na terceira forma normal, e não apenas qualquer atributo não chave é totalmente funcionalmente dependente de qualquer chave, mas qualquer atributo chave deve ser totalmente funcionalmente dependente de qualquer chave.

Assim, o requisito de que os atributos não-chave realmente dependam da chave inteira e de nada além da chave se aplica aos atributos-chave também.

Em uma relação que está na forma normal de Boyce-Codd, todas as dependências funcionais dentro da relação são impostas pela declaração de chaves. No entanto, ao reduzir as relações de banco de dados para a forma Boyce-Codd, são possíveis situações em que as dependências entre os atributos de várias relações acabam sendo dependências funcionais não impostas. Suportar tais dependências funcionais com triggers operando em tuplas de diferentes relações é mais difícil do que no caso da terceira forma normal, quando triggers operam em tuplas de uma única relação.

Entre outras coisas, a prática de projetar sistemas de gerenciamento de banco de dados mostrou que nem sempre é possível trazer a relação básica para a forma normal de Boyce-Codd.

A razão para as anomalias observadas é que os requisitos da segunda forma normal e da terceira forma normal não requerem uma dependência funcional mínima da chave primária de atributos que são componentes de outras chaves possíveis. Este problema é resolvido pela forma normal, que é historicamente chamada de forma normal de Boyce-Codd e que é um refinamento da terceira forma normal no caso da presença de várias chaves possíveis sobrepostas.

Em geral, a normalização do esquema de banco de dados torna as atualizações de banco de dados mais eficientes para o sistema de gerenciamento de banco de dados, pois reduz o número de verificações e backups que mantêm a integridade do banco de dados. Ao projetar um banco de dados relacional, você quase sempre obtém a segunda forma normal de todos os relacionamentos no banco de dados. Em bancos de dados que são atualizados com frequência, eles geralmente tentam fornecer a terceira forma normal do relacionamento. A forma normal de Boyce-Codd recebe muito menos atenção porque, na prática, são raras as situações em que uma relação tem várias chaves candidatas sobrepostas compostas.

Todos os itens acima tornam a forma normal Boyce-Codd não muito conveniente de usar ao desenvolver código de programa, portanto, como mencionado anteriormente, na prática, os desenvolvedores geralmente se limitam a trazer seus bancos de dados para a terceira forma normal. No entanto, ele também tem sua própria característica bastante curiosa. O ponto é que situações em que uma relação está na terceira forma normal, mas não na forma normal de Boyce-Codd, são extremamente raras na prática, ou seja, após a redução à terceira forma normal, geralmente todas as dependências funcionais são impostas por declarações de primária, candidata e chaves estrangeiras, portanto, não há necessidade de gatilhos para suportar dependências funcionais.

No entanto, a necessidade de gatilhos permanece para dar suporte a restrições de integridade que não estão vinculadas por dependências funcionais.

6. Aninhamento de formas normais

O que significa aninhamento de formas normais?

Aninhamento de formas normais - esta é a proporção dos conceitos de formas enfraquecidas e fortalecidas em relação umas às outras.

O aninhamento de formas normais segue completamente de suas respectivas definições. Vamos imaginar um diagrama ilustrando a relação de aninhamento das formas normais conhecidas por nós:

Vamos explicar os conceitos de formas normais enfraquecidas e fortalecidas umas em relação às outras usando exemplos concretos.

A primeira forma normal é enfraquecida em relação à segunda forma normal (e também em relação a todas as outras formas normais). De fato, lembrando as definições de todas as formas normais pelas quais passamos, podemos ver que os requisitos de cada forma normal incluíam o requisito de pertencer à primeira forma normal (afinal, isso foi incluído em cada definição subsequente).

A segunda forma normal é mais forte que a primeira forma normal, mas mais fraca que a terceira forma normal e a forma normal de Boyce-Codd. De fato, pertencer à segunda forma normal está incluído na definição da terceira, e a própria segunda forma, por sua vez, inclui a primeira forma normal.

A forma normal de Boyce-Codd não se fortalece apenas em relação à terceira forma normal, mas também em relação a todas as outras que a precedem.

E a terceira forma normal, por sua vez, é enfraquecida apenas em relação à forma normal de Boyce-Codd.

<< Voltar: Dependências funcionais (Restrição de dependência funcional. Regras de inferência de Armstrong. Regras de inferência derivadas. Completude do sistema de regras de Armstrong)

>> Encaminhar: Design de esquema de banco de dados (Diferentes tipos e multiplicidades de conexões. Diagramas. Tipos de diagramas. Relacionamentos e migração de chaves)

Recomendamos artigos interessantes seção Notas de aula, folhas de dicas:

▪ Lei de imposto. Notas de aula

▪ História nacional. Notas de aula

▪ Terapia Hospitalar. Notas de aula

Veja outros artigos seção Notas de aula, folhas de dicas.

Leia e escreva útil comentários sobre este artigo.

<< Voltar

Últimas notícias de ciência e tecnologia, nova eletrônica:

A existência de uma regra de entropia para o emaranhamento quântico foi comprovada 09.05.2024

A mecânica quântica continua a nos surpreender com seus fenômenos misteriosos e descobertas inesperadas. Recentemente, Bartosz Regula do Centro RIKEN de Computação Quântica e Ludovico Lamy da Universidade de Amsterdã apresentaram uma nova descoberta que diz respeito ao emaranhamento quântico e sua relação com a entropia. O emaranhamento quântico desempenha um papel importante na moderna ciência e tecnologia da informação quântica. No entanto, a complexidade da sua estrutura torna a sua compreensão e gestão um desafio. A descoberta de Regulus e Lamy mostra que o emaranhamento quântico segue uma regra de entropia semelhante à dos sistemas clássicos. Esta descoberta abre novas perspectivas na ciência e tecnologia da informação quântica, aprofundando a nossa compreensão do emaranhamento quântico e a sua ligação à termodinâmica. Os resultados do estudo indicam a possibilidade de reversibilidade das transformações de emaranhamento, o que poderia simplificar muito seu uso em diversas tecnologias quânticas. Abrindo uma nova regra ... >>

Mini ar condicionado Sony Reon Pocket 5 09.05.2024

O verão é uma época de relaxamento e viagens, mas muitas vezes o calor pode transformar essa época em um tormento insuportável. Conheça um novo produto da Sony – o minicondicionador Reon Pocket 5, que promete deixar o verão mais confortável para seus usuários. A Sony lançou um dispositivo exclusivo - o minicondicionador Reon Pocket 5, que fornece resfriamento corporal em dias quentes. Com ele, os usuários podem desfrutar do frescor a qualquer hora e em qualquer lugar, simplesmente usando-o no pescoço. Este miniar condicionado está equipado com ajuste automático dos modos de operação, além de sensores de temperatura e umidade. Graças a tecnologias inovadoras, o Reon Pocket 5 ajusta o seu funcionamento em função da atividade do utilizador e das condições ambientais. Os usuários podem ajustar facilmente a temperatura usando um aplicativo móvel dedicado conectado via Bluetooth. Além disso, camisetas e shorts especialmente desenhados estão disponíveis para maior comodidade, aos quais um mini ar condicionado pode ser acoplado. O dispositivo pode, oh ... >>

Energia do espaço para Starship 08.05.2024

A produção de energia solar no espaço está se tornando mais viável com o advento de novas tecnologias e o desenvolvimento de programas espaciais. O chefe da startup Virtus Solis compartilhou sua visão de usar a Starship da SpaceX para criar usinas orbitais capazes de abastecer a Terra. A startup Virtus Solis revelou um ambicioso projeto para criar usinas de energia orbitais usando a Starship da SpaceX. Esta ideia poderia mudar significativamente o campo da produção de energia solar, tornando-a mais acessível e barata. O cerne do plano da startup é reduzir o custo de lançamento de satélites ao espaço usando a Starship. Espera-se que este avanço tecnológico torne a produção de energia solar no espaço mais competitiva com as fontes de energia tradicionais. A Virtual Solis planeja construir grandes painéis fotovoltaicos em órbita, usando a Starship para entregar os equipamentos necessários. Contudo, um dos principais desafios ... >>

Notícias aleatórias do Arquivo Armadilha eletrostática para moscas 15.05.2002 Andar sobre tapetes, especialmente tapetes sintéticos, acumula uma carga eletrostática no corpo, de modo que tocar em objetos aterrados causa uma faísca. Este efeito pode ser usado para controlar moscas e outros insetos. A ideia é de dois pesquisadores da Inglaterra e dos EUA. Se você forçar uma mosca a correr alguns passos em um revestimento dielétrico, uma carga eletrostática se acumulará em suas patas. Depois de passar pelo pó dos esporos de um fungo mortal para os insetos, a mosca atrairá esses esporos e logo morrerá. Você também pode usar inseticida em pó - ele agirá mais rápido que o fungo, mas do ponto de vista ambiental, isso é indesejável. O resultado dos experimentos foi um artigo científico chamado "Triboeletrificação de moscas domésticas". Experimentos mostraram que a melhor carga estática é formada quando as moscas caminham sobre o cloreto de polivinila. Para atrair os insetos para esse caminho, um feromônio pode ser introduzido no plástico - uma substância odorífera que é atrativa para um ou outro tipo de inseto. A carga atinge a saturação depois que a mosca corre 30 centímetros.

Outras notícias interessantes:

▪ Armas anti-satélite

▪ O tecido ouve o som

▪ Fórmula da Felicidade

▪ Purificação de água de urânio usando bactérias magnéticas

▪ Photon criptografa a comunicação

Feed de notícias de ciência e tecnologia, nova eletrônica

Materiais interessantes da Biblioteca Técnica Gratuita:

▪ seção do site Materiais elétricos. Seleção de artigos

▪ artigo O que são fofocas para considerar trabalhar, não é melhor se virar sozinho, padrinho? expressão popular

▪ artigo Quem são os neandertais? Resposta detalhada

▪ artigo Gerente de Logística. Descrição do trabalho

▪ artigo Outra vida da porta LPT. Parte 3. Enciclopédia de rádio eletrônica e engenharia elétrica

▪ artigo Organização e funcionamento de instalações elétricas. Gerenciamento elétrico. Gestão operacional. Enciclopédia de rádio eletrônica e engenharia elétrica

Deixe seu comentário neste artigo:

Todos os idiomas desta página

Arabic	Hebrew	Polish
Bengali	Hindi	Portuguese
Chinese	Italian	Spanish
English	Japanese	Turkish
French	Korean	Ukrainian
German	Malay	Vietnamese

Página principal | Biblioteca | Artigos | Mapa do Site | Revisões do site

www.diagrama.com.ua
2000-2024