Embedded Files
Modelo Entidade-Relacionamento (MER)
O Modelo Entidade Relacionamento (também chamado Modelo ER, ou simplesmente MER), como o nome sugere, é um modelo conceitual utilizado na Engenharia de Software para descrever os objetos (entidades) envolvidos em um domínio de negócios, com suas características (atributos) e como elas se relacionam entre si (relacionamentos).
Em geral, este modelo representa de forma abstrata a estrutura que possuirá o banco de dados da aplicação.
Entidade
As entidades são nomeadas com substantivos concretos ou abstratos que representem de forma clara sua função dentro do domínio. Exemplos práticos de entidades comuns em vários sistemas são Cliente, Produto, Venda, Turma, Função, entre outros.
Podemos classificar as entidades segundo o motivo de sua existência:
Entidades fortes: são aquelas cuja existência independe de outras entidades, ou seja, por si só elas já possuem total sentido de existir. Em um sistema de vendas, a entidade produto, por exemplo, independe de quaisquer outras para existir.
Entidades fracas: ao contrário das entidades fortes, as fracas são aquelas que dependem de outras entidades para existirem, pois individualmente elas não fazem sentido. Mantendo o mesmo exemplo, a entidade venda depende da entidade produto, pois uma venda sem itens não tem sentido.
Entidades associativas: esse tipo de entidade surge quando há um relacionamento do tipo muitos para muitos (explicado a seguir). Nestes casos, é necessária a criação de uma entidade intermediária cuja identificação é formada pelas chaves primárias (explicado mais adiante) das outras duas entidades. No contexto de uma aplicação de vendas, como precisamos relacionar vendas e produtos numa relação muitos para muitos, a entidade produto não pode referenciar diretamente a venda, nem o inverso, pois isso caracterizaria um relacionamento um para um, ou um para muitos. Sendo assim, criamos uma entidade intermediária para representar os itens da venda, que tanto possuem a identificação do produto, quando da venda em que estão contidos. Neste caso específico, também caberiam a esta entidade informações como quantidade de itens e desconto unitário, por exemplo.
Relacionamentos
Uma vez que as entidades são identificadas, deve-se então definir como se dá o relacionamento entre elas. De acordo com a quantidade de objetos envolvidos em cada lado do relacionamento, podemos classifica-los de três formas:
Relacionamento 1..1 (um para um): cada uma das duas entidades envolvidas referenciam obrigatoriamente apenas uma unidade da outra. Por exemplo, em um banco de dados de currículos, cada usuário cadastrado pode possuir apenas um currículo na base, ao mesmo tempo em que cada currículo só pertence a um único usuário cadastrado.
Relacionamento 1..n ou 1..* (um para muitos): uma das entidades envolvidas pode referenciar várias unidades da outra, porém, do outro lado cada uma das várias unidades referenciadas só pode estar ligada uma unidade da outra entidade. Por exemplo, em um sistema de plano de saúde, um usuário pode ter vários dependentes, mas cada dependente só pode estar ligado a um usuário principal. Note que temos apenas duas entidades envolvidas: usuário e dependente. O que muda é a quantidade de unidades/exemplares envolvidas de cada lado.
Relacionamento n..n ou *..* (muitos para muitos): neste tipo de relacionamento cada entidade, de ambos os lados, podem referenciar múltiplas unidades da outra. Por exemplo, em um sistema de biblioteca, um título pode ser escrito por vários autores, ao mesmo tempo em que um autor pode escrever vários títulos. Assim, um objeto do tipo autor pode referenciar múltiplos objetos do tipo título, e vice versa.
Atributos
Atributos são as características que descrevem cada entidade dentro do domínio. Por exemplo, um cliente possui nome, endereço e telefone.
Os atributos podem ser classificados quanto à sua função da seguinte forma:
Descritivos: representam característica intrínsecas de uma entidade, tais como nome ou cor.
Nominativos: além de serem também descritivos, estes têm a função de definir e identificar um objeto. Nome, código, número são exemplos de atributos nominativos.
Referenciais: representam a ligação de uma entidade com outra em um relacionamento. Por exemplo, uma venda possui o CPF do cliente, que a relaciona com a entidade cliente.
Diagramas Entidade-Relacionamento (DER)
Enquanto o MER é um modelo conceitual, o Diagrama Entidade Relacionamento (Diagrama ER ou ainda DER) é a sua representação gráfica e principal ferramenta.
Em situações práticas, o diagrama é tido muitas vezes como sinônimo de modelo, uma vez que sem uma forma de visualizar as informações, o modelo pode ficar abstrato demais para auxiliar no desenvolvimento do sistema.
O diagrama facilita ainda a comunicação entre os integrantes da equipe, pois oferece uma linguagem comum utilizada tanto pelo analista, responsável por levantar os requisitos, e os desenvolvedores, responsáveis por implementar aquilo que foi modelado.
Nos diagramas, usa-se a notação UML, em que os atributos já aparecem listados na própria entidade. Abaixo segue um exemplo de um Diagrama Entidade-Relacionamento.
Uma variante da figura anterior pode ser vista na figura seguinte, onde a cardinalidade do relacionamento é exibida junto do losango.
Uma outra variação já mostra a cardinalidade de uma forma mais completa, deixando claro as possibilidades de números de objetos envolvidos em cada relacionamento. Nesse modelo, em cada lado do relacionamento os números aparecem no formato (X,Y) ao invés de um único número como vemos nas figuras anteriores. A próxima figura ilustra um exemplo desse tipo.
Neste diagrama, lemos os relacionamentos da seguinte forma:
1 ou 1 grupo possui 0 ou muitos produtos. Como de um lado temos “1 ou 1”, isso equivale a apenas “1”, pois não temos várias possibilidades. Já do lado do produto, indicamos que um grupo pode possuir nenhum produto, mas também pode possuir vários.
0 ou várias vendas contém 1 ou muitos produtos. Ou seja, um produto pode nunca ser vendido (0 vendas) como também pode ser vendido várias vezes (n vendas). Já uma venda deve conter 1 ou vários produtos, pois uma venda não pode estar vazia (0 produtos).
Na notação UML, os atributos aparecem listados dentro do próprio retângulo da entidade, enquanto o nome da entidade aparece no topo na forma de título. Na figura a seguir temos um exemplo.
Procedures
Stored Procedures nada mais são do que um conjunto de instruções Transact-SQL que são executadas dentro do banco de dados. É como escrever um programa dentro do próprio banco de dados para executar tudo lá dentro.
Dentro das Stored Procedures devemos utilizar comandos Transact-SQL que não deixam nada a desejar a comandos de uma liguagem de programação qualquer, como C++, Python, Java, etc. O Transact-SQL
possui instruções de comparação (if), loops (while) operadores, variáveis, funções, etc. A seguir temos um exemplo de como criar uma procedure chamada MINHAFUNCAO no MySQL.
mysql> delimiter //
-> create procedure MINHAFUNCAO (out SAIDA int)
-> begin
-> select count(*) into SAIDA from TABELA_ESPECIFICA;
-> end//
mysql>delimiter ;
mysql> call MINHAFUNCAO (@RETORNO);
mysql> select @RETORNO;
Functions
Funções e procedures servem propósitos diferentes.
Uma função, pensando na sua definição matemática, é usada normalmente para calcular um valor com base num determinado input. Uma função não permite alterações fora do seu "scope" (escopo), isto é, não pode ser utilizada para alterar o estado global da base de dados (por exemplo, através das instruções INSERT, UPDATE, DELETE).
Por seu lado, as procedures podem ser vistas como programas/scripts (se fizermos uma analogia com uma qualquer linguagem de programação). Uma procedure permite alterar o estado global da base de dados (por exemplo, a utilização das instruções INSERT, UPDATE, DELETE). Procedures são utilizadas normalmente para juntar várias queries numa única transação.
Abaixo segue o exemplo de como se define uma função no MySQL:
mysql> CREATE FUNCTION hello (s CHAR(20)) mysql> RETURNS CHAR(50) DETERMINISTIC -> RETURN CONCAT('Hello, ',s,'!'); Query OK, 0 rows affected (0.00 sec) mysql> SELECT hello('world');
Triggers
Um trigger (gatilho) é um tipo especial de procedimento armazenado, que é executado sempre que há uma tentativa de modificar os dados de uma tabela que é protegida por ele.
Os TRIGGERS são definidos em uma tabela específica, que é denominada tabela de TRIGGERS;
Quando há uma tentativa de inserir, atualizar ou excluir os dados em uma tabela, e um TRIGGER tiver sido definido na tabela para essa ação específica, ele será executado automaticamente, não podendo nunca ser ignorado.
Ao contrário dos procedimentos armazenados do sistema, os disparadores não podem ser chamados diretamente e não passam nem aceitam parâmetros.
O TRIGGER e a instrução que o aciona são tratados como uma única transação, que poderá ser revertida em qualquer ponto do procedimento, caso você queria usar “ROLLBACK”, conceitos que veremos mais a frente.
Para que um TRIGGER seja disparado, o usuário o qual entrou com as instruções, deverá ter permissão de acessar tanto a entidade e consequentemente ao TRIGGER.
Os TRIGGERS são usados com enorme eficiência para impor e manter integridade referencial de baixo nível, e não para retornar resultados de consultas. A principal vantagem é que eles podem conter uma lógica de processamento complexa.
Você pode usar TRIGGERS para atualizações e exclusões em cascata através de tabelas relacionadas em um banco de dados, impor integridades mais complexas do que uma restrição CHECK, definir mensagens de erro personalizadas, manter dados desnormalizados e fazer comparações dos momentos anteriores e posteriores a uma transação.
A seguir temos a "regra" de como se criar um trigger:
CREATE [DEFINER = { user | CURRENT_USER }] TRIGGER trigger_name trigger_time trigger_event ON tbl_name FOR EACH ROW trigger_bodytrigger_time: { BEFORE | AFTER } trigger_event: { INSERT | UPDATE | DELETE }
Restrições de Integridade
Uma base de dados está num estado de integridade se contém apenas dados válidos.
Quando um dado é inserido, alterado ou apagado o SGBD (Sistema de Gerenciamento de Bancos de Dados) vai verificar se as regras definidas são respeitadas.
Relação, definição:
Relação r(R)
Conjunto de tuplas: r = {t1 ,t2 , ..., tm}
Cada tupla é uma lista ordenada de valores: t = <v1, v2,..., vn>
Attributo Ai na tupla t: t[Ai ]
Características de uma relação:
Uma tupla é uma lista ordenada de valores;
O valor de cada atributo em uma tupla é atômico:
Atributos compostos e multivalorados NÃO são permitidos;
O valor especial null é utilizado para representar valores não conhecidos ou não aplicáveis a uma determinada tupla.
As restrições de Integridade básicas são:
Restrições de domínio
Define o conjunto de valores possíveis ou permitidos que um campo pode ter.
Restrições de chave
Impede que uma chave primária se repita. Um campo chave primária diferencia de forma única os registros (linhas) de uma relação (tabela)
Restrições em valores null (ou Integridade de vazio)
Especifica se a um atributo é permitido ou não ter valores null . Exemplo:
Todo Aluno deve ter um nome válido, NOT NULL;
Nem todo Aluno possui telefone, NULL;
Integridade Referencial
Uma chave estrangeira de uma relação tem que coincidir com uma chave primária da sua tabela "pai" a que a chave estrangeira se refere. Ou seja, não só deve existir o atributo (campo), como também, o valor referenciado.
Views
Uma VIEW (ou Visão) é uma consulta armazenada no banco de dados. Nós podemos, realizar consultas sobre uma VIEW como se fosse uma tabela. Muitas pessoas se referem às VIEWs como uma tabela virtual.
Uma das principais funções da VIEW é controlar a segurança do banco de dados. Geralmente se cria a VIEW (uma consulta armazenada no banco de dados) com os campos que determinado perfil de usuário pode acessar, e concede-se ao usuário acesso apenas a essa VIEW e não à(s) tabela(s) diretamente.
Também utiliza-se VIEWs para apresentar informações mais organizadas para o usuário sem que ele precise elaborar uma consulta complexa. Esta já estaria pronta e armazenada no próprio banco de dados para uso.
Para entender o que é uma VIEW na prática, imagine as duas tabelas abaixo.
Agora considere que um determinado usuário precisa de uma lista atualizada de Funcionários e seus respectivos departamentos. Por questões de segurança, não pode ser fornecido à este usuário informações de CPF, E-mail e Salário dos funcionários.
A melhor forma para se fazer isso é criar uma VIEW onde essas informações não apareçam e fornecer ao usuário acesso apenas a esta VIEW. Ou seja, o usuário só teria acesso visão conforme a imagem abaixo.
Abaixo segue um exemplo muito simples e prático de como se criar uma View no MySQL:
mysql> CREATE TABLE t (qty INT, price INT); mysql> INSERT INTO t VALUES(3, 50); mysql> CREATE VIEW v AS SELECT qty, price, qty*price AS value FROM t; mysql> SELECT * FROM v; +------+-------+-------+ | qty | price | value | +------+-------+-------+ | 3 | 50 | 150 | +------+-------+-------+
Entre as diversas vantagens que se tem de usar uma view, dois exemplos são ilustrados a seguir:
Economizar tempo com retrabalho;
Ex.: Você não precisar escrever aquela instrução enorme. Escreva uma vez e armazene!
Velocidade de acesso às informações;
Ex.: Uma vez compilada, o seu recordset (conjunto de dados) é armazenado em uma tabela temporária (virtual).
MATERIALIZED VIEW
Visão Materializada é uma view, só que neste caso, o que é armazenado não é a consulta e sim o resultado dela.
Isso implica algumas coisas muito importantes que devem ser entendidas quando for decidir entre criar uma VIEW ou uma MATERIALIZED VIEW.
Primeiro, uma MATERIALIZED VIEW é uma tabela real no banco de dados que é atualizada SEMPRE que ocorrer uma atualização em alguma tabela usada pela sua consulta. Por este motivo, no momento em que o usuário faz uma consulta nesta visão materializada o resultado será mais rápido que se ela não fosse materializada.
Basicamente a diferença no uso das duas é essa. A view realiza a consulta no momento que o usuário faz uma consulta nela e a materialized view realiza a consulta no momento em que uma das tabelas consultadas é atualizada.
Vejamos como seria na prática com o mesmo exemplo que utilizamos acima.
Se a view V_FUNCIONARIO_DEPARTAMENTO exemplificada anteriormente for materializada, sempre que a tabela departamento ou a tabela funcionário receber uma inclusão, alteração ou exclusão, a “consulta da view” também será executada e o resultado será armazenado.
Embora a consulta na view fique mais rápida com o pre-processamento da consulta interna, o processo de escrita no banco de dados fica mais lento, pois é necessário executar a consulta interna da materialized view toda vez que um dado sofrer alteração.
Quando usar VIEW ou MATERIALIZED VIEW?
A decisão se a sua view deve ser simples ou materializada é tomada com base no tipo de utilização das tabelas usadas pela consulta da view. A decisão é simples. Você consulta mais na view do que altera os dados das tabelas? Os dados do seu banco de dados são alterados com frequência?
Em resumo, você deve usar uma visão materializada quando o desempenho das buscas na view é mais importante que o desempenho da escrita nas tabelas que ela utiliza. Mas se uma tabela utilizada pela view tem muita alteração de dados, talvez seja mais interessante que a view não seja materializada.
Segurança em Bancos de Dados
Os bancos de dados SQL implementam mecanismos que restringem ou permitem acessos aos dados de acordo com papeis ou roles fornecidos pelo administrador. O comando GRANT concede privilégios específicos para um objeto (tabela, visão, seqüência, banco de dados, função, linguagem procedural, esquema ou espaço de tabelas) para um ou mais usuários ou grupos de usuários.
A preocupação com a criação e manutenção de ambientes seguros se tornou a ocupação principal de administradores de redes, de sistemas operacionais e de bancos de dados. Pesquisas mostram que a maioria dos ataques, roubos de informações e acessos não- autorizados são feitos por pessoas que pertencentes à organização alvo.
Segurança da Informação é a disciplina que visa preservar a confidencialidade, a integridade e a disponibilidade da informação (CID). São estes os três pilares detalhados a seguir:
Integridade
Refere ao requisito de que a informação seja protegida contra modificação imprópria.
Disponibilidade
Refere-se a tornar os objetos disponíveis a um usuário ou a um programa ao qual eles têm um direito legitimo.
Confidencialidade
Refere à proteção dos dados contra a exposição não autorizada. O impacto da exposição não autorizada de informações confidenciais pode resultar em perda de confiança pública, constrangimento ou ação legal contra a organização.
A seguir são exemplificadas algumas maneiras de como melhorar a segurança em Bancos de Dados
Controle de Acesso
É todo controle feito quanto ao acesso ao BD, impondo regras de restrição, através das contas dos usuários. O Administrador do BD (DBA) é o responsável superior por declarar as regras dentro do SGBD. Ele é o responsável por conceder ou remover privilégios, criar ou excluir usuários, e atribuição de um nível de segurança aos usuários do sistema, de acordo com a política da empresa.
Controle de Inferência (estatística)
É um mecanismo de segurança para banco de dados estatísticos que atua protegendo informações estatísticas de um individuo ou de um grupo. Bancos de dados estatísticos são usados principalmente para produzir estatísticas sobre várias populações.
O banco de dados pode conter informações confidenciais sobre indivíduos. Os usuários têm permissão apenas para recuperar informações estatísticas sobre populações e não para recuperar dados individuais, como, por exemplo, a renda de uma pessoa específica.
Controle de Fluxo
É um mecanismo que previne que as informações fluam por canais secretos e violem a política de segurança ao alcançarem usuários não autorizados. Ele regula a distribuição ou fluxo de informação entre objetos acessíveis.
Um fluxo entre o objeto A e o objeto B ocorre quando um programa lê valores de A e escreve valores em B. Os controles de fluxo têm a finalidade de verificar se informações contidas em alguns objetos não fluem explicita ou implicitamente para objetos de menor proteção. Dessa maneira, um usuário não pode obter indiretamente em B aquilo que ele ou ela não puder obter diretamente de A.
Criptografia de Dados
É uma medida de controle final, utilizada para proteger dados sigilosos que são transmitidos por meio de algum tipo de rede de comunicação. Ela também pode ser usada para oferecer proteção adicional para que partes confidenciais de um banco de dados não sejam acessadas por usuários não autorizados. Para isso, os dados são codificados através da utilização de algum algoritmo de codificação. Assim, um usuário não autorizado terá dificuldade para decifrá-los, mas os usuários autorizados receberão chaves para decifrar esses dados. A criptografia permite o disfarce da mensagem para que, mesmo com o desvio da transmissão, a mensagem não seja revelada.
Usuários
Abrange usuários e esquema do banco de dados onde cada banco de dados Oracle tem uma lista de nomes de usuários. Para acessar um banco de dados, um usuário deve usar um aplicativo desse tipo e tentar uma conexão com um nome de usuário valido. Cada nome tem uma senha associada para evitar o uso sem autorização.
Devem ser implementados ainda diferentes perfis de usuário para diferentes tarefas no Oracle, tendo em vista que cada aplicação/usuário tem a sua necessidade de acesso. Existe ainda a possibilidade de proteger os perfis com senha, o que é uma excelente medida. Além dessas medidas, o uso de cotas aumenta a restrição de espaço em disco a ser utilizado por usuários/aplicativos.
Domínio de Segurança
Onde cada usuário tem um domínio de segurança, um conjunto de propriedades que determinam coisas como ações (privilégios e papeis) disponíveis para o usuário; cota de tablespaces (espaço disponível em disco) do usuário; limites de recursos de sistema do usuário.
As tabelas (tablespaces) do sistema, como a system, devem ser protegidas de acessos de usuários diferentes dos usuários de sistema. A liberação de escrita e alteração de dados em tais tabelas é muito comum em ambientes de teste, onde os programadores e DBAs tomam tal atitude para evitar erros de aplicação por falta de privilégios. Porém, em ambientes de produção, tal medida é totalmente desaconselhável.
Autoridade
As autoridades fornecem um método de agrupar privilégios e controlar o nível de acesso dos administradores e operadores da base de dados com relação à manutenção e operações permitidas. As especificações da base de dados estão armazenadas em catálogos da própria base de dados. As autoridades do sistema estão associadas a membros de grupos e armazenados no arquivo de configuração administrativa do banco de dados. Este arquivo define as concessões de acesso e o que poderá ser executado de acordo com cada grupo.
Privilégios
Os privilégios são permissões únicas dadas a cada usuário ou grupo. Eles definem permissões para tipos de autorização. Pelos privilégios é possível autorizar o usuário a modificar ou alcançar determinado recurso do Banco de Dados.
Tipos de privilégios discricionários
O SGBD deve oferecer acesso seletivo a cada relação do banco de dados baseando-se em contas específicas. As operações também podem ser controladas; assim, possuir uma conta não necessariamente habilita o possuidor a todas as funcionalidades oferecidas pelo SGBD. Informalmente existem dois níveis para a atribuição de privilégios para o uso do sistema de banco de dados:
O nível de conta:
Nesse nível, o DBA estabelece os privilégios específicos que cada conta tem, independente das relações no banco de dados.
O nível de relação (tabela):
Nesse nível, o DBA pode controlar o privilégio para acessar cada relação ou visão individual no banco de dados.
Revogação de privilégios
Em alguns casos, interessa conceder um privilégio temporário a um usuário. Por exemplo, o proprietário de uma relação pode querer conceder o privilégio SELECT a um usuário para uma tarefa específica e depois revogar aquele privilégio quando a tarefa estiver completada. Por isso, é necessário um mecanismo para a revogação de privilégios. Em SQL, um comando REVOKE é introduzido com o intento de cancelar privilégios.
Controle de acesso obrigatório e para segurança multi-nível
Neste método, o usuário não tem um meio termo, ou ele tem ou não tem privilégios, sendo utilizado normalmente em BD que classificam dados de usuários, onde é necessário um nível a mais de segurança. A maioria dos SGBDs não oferecem esse tipo de controle de acesso obrigatório, ficando com os controles discricionários ditos anteriormente. Normalmente são utilizados em sistemas governamentais, militares ou de inteligência, assim como industriais e corporativas.
As classes de segurança típicas são altamente sigilosas (top secret, TS), secreta (secret, S), confidenciais (confidential) (C) e não Classificada (unclassified, U), em que TS é o nível mais alto e U é o mais baixo.
De uma forma geral, os mecanismos de controle de acesso obrigatório impõem segurança multinível, pois exigem a classificação de usuários e de valores de dados em classes de segurança e impõem as regras que proíbem o fluxo de informação a partir dos níveis de segurança mais altos para os mais baixos.
Controle de acesso baseado em papéis
O conceito de controle de acesso baseado em papéis surgiu com os primeiros sistemas computacionais multiusuários interativos. A ideia central do RBAC é que permissões de acesso são associadas a papéis, e estes papéis são associados a usuários. Papéis são criados de acordo com os diferentes cargos em uma organização, e os usuários são associados a papeis de acordo com as suas responsabilidades e qualificações. Vários indivíduos podem ser designados para cada papel. Os privilégios de segurança comuns a um papel são concedidos ao nome dele, e qualquer indivíduo designado para esse papel automaticamente teria esses privilégios concedidos.
Os usuários podem ser facilmente remanejados de um papel para outro. Mudanças no ambiente computacional, como instalação de novos sistemas e remoção de aplicações antigas, modificam apenas o conjunto de permissões atribuídas aos diferentes papeis, sem envolver diretamente o conjunto de usuários.
A separação de tarefas é um requisito importante em diversos SGDBs. É necessária para impedir que um usuário realize sozinho o trabalho que requer o envolvimento de outras pessoas. A exclusão mútua de papéis é um método que pode ser implementado com sucesso.
Outro aspecto relevante nos sistemas RBAC são as restrições temporais possíveis que podem existir nos papéis, como o tempo e a duração das ativações de papéis e o disparo temporizado de um papel por uma ativação de outro papel. O uso se um modelo RBAC é um objetivo altamente desejado para solucionar os principais requisitos de segurança das aplicações baseadas na web.
Controle de acesso utilizando Triggers
Com a utilização das Triggers é possível criar mecanismos de segurança mais complexos que podem ser disparados cada vez que um evento é chamado. O comando Insert na tabela é exemplo de um evento que pode ser usado para disparar uma Triggers, além disso, as mesmas podem ser disparadas antes ou depois de comando especificado com o objetivo de prover maior rigor no controle de segurança.
Se o comando executado pelo usuário não for validado pela Triggers, um erro é sinalizado do corpo da própria Triggers para impedir que a tabela seja modificada indevidamente.
Controle de acesso utilizando Views
As views constituem um outro método de controle de acesso, normalmente utilizadas para restringir o acesso direto aos dados. Com a view é possível permitir acesso de usuário concedendo privilégios, ocultar linhas e colunas de informações confidenciais ou restritas residentes na tabela original das indicações do SQL.
Os privilégios e concessões são definidos somente na view e não afetam a tabela base sendo o acesso dos usuários delimitado pela view, a qual é gerada criando um subconjunto de dados na tabela referenciada.
Para finalizar, modificações no esquema do banco de dados ou na descrição da organização da armazenagem física, embora relativamente raras, são executadas escrevendo-se um conjunto de definições que são usadas pelo compilador de DDL ou pelo compilador de estruturas de dados e linguagem de definição para gerar modificações nas respectivas tabelas internas do sistema (como, por exemplo, o dicionário de dados).
Fontes:
http://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-entidade-relacionamento-der/14332
http://imasters.com.br/artigo/223/sql-server/criacao-e-uso-de-stored-procedures
http://dev.mysql.com/doc/refman/5.6/en/create-procedure.html
http://dev.mysql.com/doc/refman/5.6/en/create-trigger.html
http://pt.stackoverflow.com/questions/60323/qual-a-diferen%C3%A7a-entre-function-e-procedure
http://www.devmedia.com.br/introducao-a-triggers/1695
http://www.di.ubi.pt/~pprata/bd/BD_05_06_T5.pdf
http://www3.ifrn.edu.br/~claytonmaciel/files/20111/bd/Aula%206%20-%20Modelo%20Relacional%20-%20Introducao%20e%20Restricoes%20de%20Integridade.pdf
https://pt.wikipedia.org/wiki/Restri%C3%A7%C3%B5es_de_integridade
http://www.devmedia.com.br/introducao-a-views/1614
http://www.dicasdeprogramacao.com.br/qual-a-diferenca-entre-view-e-materialized-view/
http://dev.mysql.com/doc/refman/5.6/en/create-view.html
http://www.diegomacedo.com.br/conceitos-sobre-seguranca-em-banco-de-dados/
http://www.ime.usp.br/~andrers/aulas/bd2005-1/aula5.html
Page updated
Google Sites
Report abuse