Criando uma view para essas duas tabelas contendo os dados pertinentes de

ambas, a VIEW cria como se fosse uma tabela virtual, ela pode ser consultada mais
facilmente para obter os resultados, mas não está fisicamente gravando dados,
representa uma visão de dados e sem os conter fisicamente de fato. É um
metadado que mapeia uma query para outra, por isto pode ser considerado como
uma tabela virtual. As vantagens em usar um VIEW neste caso seriam: Reuso,
Segurança e Simplificação do código.

Não pode ser atualizada. Por ser uma VIEW e também estar utilizando o GROUP BY
ela permite operações de SELECT ou operações para alterar a VIEW, como por
exemplo colunas a serem inseridas ou removidas da visualização, criar ou deletar
uma VIEW, mas para alterar os dados em si deve-se alterar eles acessando suas
respectivas tabelas uma vez que o AVG, GROUP BY acaba bloqueando essa função.

“Você faz operações linha-a-linha no banco, registro por registro. Se vc tem uma
view que faz uso de agregação (group by, avg, count) e coisas do tipo, vc joga no lixo
essa "atomicidade". Logo, não faria operações em cima de registros "únicos" que
existem de fato, mas sim em registros que não existem e que são resultados de
outros registros que existem e não podem ser identificados unicamente.”
 Sequences correspondem a um objeto de banco que é uma outra estratégia
possível para a geração de identificadores, o uso comum de Sequences é gerar
identificadores para IDs, chaves artificiais ou chaves surrogadas. Uma Sequence é
um objeto que gera uma sequencia de números únicos. Em suma a geração de
sequences é no banco de dados, afinal é um objeto de banco, o SGBD não tem
participação direta.

CREATE SEQUENCE SQ_ITEM

INCREMENT BY 2 START WITH 15;

No comando acima o valor da Sequence é iniciado em 15 e será acrescentado de 2

em 2, logo se usarmos NEXTVAL a sequence nos devolverá o número 15. Se
usarmos o CURVAL ele nos retorna o ultimo valor retornado pela Sequence para a
nossa sessão, nesse caso seria o 15, mas atenção é o ultimo valor usado na sessão,
ele não reflete no ultimo valor usado pelo Sequence.

Tempo Usuario A Usuario B Usuario C

T1 15

T2 17

T3 19

T6 17

T5 19

T6 15
 Usando Sequence é possivel que tenhamos buracos na sequência, um
exemplo é quando uma operação não teve sucesso e gera um buraco, nesse sentido
sabemos que o Sequence ignorará esses buracos e continuará apenas
acrescentando ao seu contador atual o valor da sequencia em si.
O mais adequado para resolver isso seria usar o SELECT … FOR UPDATE, em
conjunto de uma tabela de apenas um número que será utilizado como uma
sequência, assim a transação só acrescetará ao contador se uma transação ocorreu
corretamente e não houve buracos, caso contrário, haverá um rollback sem commit
dos dados, não havendo a criação de burracos na sequência.

Ao final da execução de todos os comando acima o USER3 pode executar

apenas os comandos concedidos pelos USER1, SELECT e DELETE, uma vez que o
REVOKE feito pelo ADMIN em USER2 remove todos os privilégios fornecidos por ele
em cascata.
 O indíce usado normalmente para atributos de domínio esparso é o indíce
bitmap, nele para cada valor do domínio existe um bitmap que identifica quais rows
satisfazem as tuplas.
Veja um exemplo da Internet, seria essa uma tabela chamada MoviesRating que
possui os elementos Id, Rating e Name onde Rating só pode possuir os valores 1, 2
ou 3 e possui um index bitmap.

Id Rating etc

22 1 Other data

23 2 Other data

31 3 Other data

35 1 Other data

Tabela bitmap, que exibe o index da coluna rating

1 2 3

1 0 0

0 1 0

0 0 1

1 0 0
Usando o SGBD PostgressSQL. Até o momento as transações foram muitos úteis
em ambientes stand alone, onde trabalhamos apenas com uma thread por vez, sem
concorrência. Em cenários que trabalham com tarefas concorrentes a estória muda
de contexto e já precisamos pensar em como isolar determinadas transações, não
permitindo que uma alteração de dados na transação A afete a execução da
transação B.

Os níveis de isolamento só existem porque existem problemas ao trabalhar-se com

transações concorrente, e antes de vermos quais são esses níveis e como aplicá-los,
nós temos que entender que tipo de problemas podem ocorrer ao trabalhar em
multithread.

São três os possíveis problemas que você encontrará: Dirty Read, Nonrepeatable
Read e Phatom Read.

READ UNCOMMITTED (leiturade dados não efetivada): nível menos isolado e que
possibilita a leiturade uma transação antes que esta seja confirmada, ou seja,
permite que uma transação ainda não efetivada (committed ) seja lida (consultad a)
por uma transação e, depois dessa leitura, atransação pode sofrer um rollback e a
alteração ser desfeita (a transaçã o B leu um dado da transaçã o que não existe
mais, porque foi desfeito). Esse tipo de problema é chama do dirty reads (leituras
sujas).READ COMMITTED (leitura efetivada): o segundo nível de isolamento é o
nível-padrão da maioria dos SGBD, inclusive o PostgreSQL. Não promove problemas
do tipo dirty reads, porém permite os non-repeatable reads ( leituras não repetíveis),
que acontecem quando um atransação altera o valor de um objeto do banco de
dados B que foi lido por uma transação C, alteração que se deu enquanto a
transação C lia o objeto B. Assim, se a transação C ler novamente o objeto B, ela terá
um resultado diferente do primeiro, porque este já foi alterado.

REPEATABLE READ (leitura repetível): embora o terceiro nível não permita que
aconteçam os problemas de dirty reads e non-repeatable reads dos níveis 1 e 2,
podem acontecer os chamados phantoms (fantasmas). Estes surgem quando uma
transação A poderia sobrescrever o valor de um objeto B, já modificado por uma
transação C, enquanto atransação C ainda está em andamento, mesmo que atransa
çã o A não leia o valor do objeto B gravado pela transação C. Isso quer dizer que
atransação A sobrescreve o dado alterado na transaçã o C antes de atransação C
terminar, ou seja, a alteração da transaçã o C não surtirá efeito porque foi
sobrescrita.

SERIALIZABLE (serializável): as instruções não podem ler dados que foram

modificados, mas que ainda não foram confirmados por outras transações.
Nenhuma outra transação pode modificar dados lidos pela transação atual até que a
transação atual seja concluída.
Outras transações não podem inserir linhas novas com valores chave que estejam
no intervalo de chaves lido por qualquer instrução da transação atual até que esta
seja concluída.
Bloqueios de intervalo são colocados no intervalo de valores chave que corresponde
às condições de pesquisa de cada instrução executada em uma transação. Isso
bloqueia que outras transações atualizem ou insiram qualquer linha que seja
qualificada para qualquer uma das instruções executadas pela transação atual. Isto
significa que, se qualquer uma das instruções de uma transação for executada uma
segunda vez, ela lerá o mesmo conjunto de linhas. Os bloqueios de intervalo são
mantidos até que a transação seja concluída. Esse é o mais restritivo dos níveis de
isolamento, pois ele bloqueia intervalos de chaves inteiros até que a transação seja
concluída. Como a simultaneidade é menor, use essa opção apenas quando
necessário. Essa opção tem o mesmo efeito de definir HOLDLOCK em todas as
tabelas em todas as instruções SELECT de uma transação.

No Oracle para dar permissão de visualização é necessário utilizar o função

GRAND SELECT e inserir as colunas que serão visualizadas entre parenteses.
ex:
GRANT SELECT (coluna_1, coluna_2) ON tabela_T to USER1;