Prof. Arthur Mendonça

Aula 01

Banco de Dados para Auditor Fiscal da SEFAZ /PR

Prof. Arthur Mendonça

Sumário

SUMÁRIO 2

INTRODUÇÃO 3

TEORIA DA AULA 4

OMODELO RELACIONAL 4

Relações 4

Tuplas 5

Atributos 6

Domínio 8

CHAVES 9

Chave Primária 10

Chave Estrangeira 11

Chave Candidata 13

RELACIONAMENTOS 14

Autorrelacionamentos 19

INTEGRIDADE,ÍNDICES,VIEWS E NORMALIZAÇÃO 20

Integridade 20

Índices 21

Views (visões) 22

Normalização 24

AS 12 REGRAS DE CODD 27

QUESTÕES COMENTADAS PELO PROFESSOR 34

LISTA DE QUESTÕES COMENTADAS 60

GABARITO 75

RESUMO DIRECIONADO 76

BIBLIOGRAFIA 78

Introdução

Olá, caro aluno! Bem-vindo a mais uma aula de Banco de Dados para Auditor Fiscal da SEFAZ/PR. Na aula de hoje vamos contemplar o seguinte assunto, que foi cobrado no último concurso e deve estar presente no seu edital:

Modelagem de Dados Relacional.

Ao final da aula, encerraremos a nossa visão geral a respeito desses bancos de dados convencionais, que estão presentes nos mais diversos negócios e aplicações. O assunto de hoje é bem importante, pois sempre aparece em provas.

Vamos lá?

Teoria da Aula

O Modelo Relacional

Já vimos o básico a respeito de bancos de dados em sentido amplo na última aula, mas ainda restou a dúvida:

o que é um banco de dados relacional?

O modelo relacional foi introduzido por um americano chamado Ted Codd (1970). Esse modelo de dados se baseia em coisas complicadas como teoria dos conjuntos e lógica de predicados para formalizar os conceitos básicos, mas vou tentar apresentar de uma maneira mais simples e didática para você.

O modelo relacional apresenta três características marcantes:

1. Os dados estão sempre armazenados em tabelas;

2. Há um conjunto de restrições de integridade em relação a essas tabelas;

3. Há o uso de operadores relacionais para trabalhar com as tabelas de dado, que são implementados na linguagem SQL.

A seguir, vamos começar falando um pouco sobre cada um dos principais componentes de um BD relacional.

Você vai ver que diversos dos conceitos que mostraremos já foram trabalhados na aula anterior. A diferença é que, na aula anterior, falamos de tudo no nível de modelo conceitual, de forma mais abstrata. Hoje vamos ter um enfoque em como cada um desses conceitos está representado nas tabelas de um banco de dados.

Relações

Os bancos de dados são exemplos de coleções de dados estruturados. Isso acontece porque os dados estão armazenados em estruturas fixas, que seguem um esquema predefinido. Com isso em mente, temos que os bancos de dados relacionais recebem esse nome porque os dados ficam armazenados em relações.

Essas relações de um BD relacional são frequentemente chamadas de tabelas. Trata-se de estruturas fixas compostas por linhas e colunas, onde cada linha é chamada de tupla e cada coluna corresponde a um atributo.

Numa tabela de clientes, por exemplo, cada tupla diz respeito a um registro de um determinado cliente do mundo real e o valor presente em cada atributo guarda relação com alguma característica desse cliente.

É mais ou menos assim:

Como acabamos de ver, as tuplas são as linhas ou registros dentro de uma relação em um BD relacional.

Portanto, de acordo com o modelo matemático que serve de base para a modelagem relacional, uma relação pode ser definida formalmente como sendo um conjunto não ordenado de tuplas.

As relações têm uma propriedade chamada grau. O grau de uma relação é dado pela quantidade de atributos de suas tuplas. A relação que mostramos acima tem quatro colunas ou atributos, portanto tem grau 4. Esse grau, teoricamente, pode variar de 0 a N. Na prática, os SGBDs costumam impedir que sejam criadas tabelas sem colunas, de grau 0. Para fins de prova, considere a teoria mesmo.

Observe que as relações geralmente guardam alguma similaridade com o conceito de entidade na modelagem conceitual.

De fato, as entidades costumam ser implementadas diretamente em tabelas dos bancos de dados relacionais, cada entidade na sua tabela.

Contudo, essa “tradução” do modelo conceitual para o físico nem sempre é exata, já que existem tabelas em um banco de dados relacional que não têm correspondência com nenhuma entidade específica do modelo conceitual. Da mesma maneira, nem todos os atributos do modelo conceitual viram algum atributo específico de uma tabela.

Essas diferenças se devem ao fato de que o modelo conceitual se preocupa muito mais em representar os aspectos do mundo real, do negócio, do que em mostrar como os dados estarão representados no banco de dados.

Tuplas

Por sua vez, as tuplas podem ser definidas como sendo os conjuntos de valores de atributos que compõem uma relação. Assim, a primeira tupla da nossa tabela de exemplo mais acima seria o conjunto Tupla1 = {CPF:

204.776.124-22, Nome: José da Silva, Dt. Nascimento: 01/05/1990, Cidade: Rio de Janeiro}.

Em uma relação, vários ordenamentos de tuplas são possíveis sem que se descaracterize sua natureza original. Na nossa tabela de exemplo, poderíamos ordenar os clientes pelo número do CPF, pela data de nascimento, pela ordem alfabética do nome ou pela cidade, mas mesmo com essas ordenações diferentes, os objetos resultantes continuariam sendo considerados a mesma relação.

Entenda que, como os registros de um banco de dados estão fisicamente armazenados em um disco, eles naturalmente vão seguir alguma ordem de armazenamento: primeiro inserimos um registro, depois outro, depois outro e assim sucessivamente. Contudo, como apontam Elmasri & Navathe (2011), uma relação não é “sensível” a

Tuplas

Atributos

Relação

essa ordem. Se essas linhas estivessem armazenadas no disco em qualquer outra ordem, a tabela seria considerada a mesma.

Assim, grave que, tanto no modelo relacional formal (teórico) quanto na prática, a ordem das tuplas (linhas) em uma relação (tabela) não é relevante.

Para resumir o que mais precisamos saber a respeito das tuplas, temos que o autor C. J. Date (2004) definiu algumas propriedades interessantes que podem ser alvo de cobrança na sua prova:

• Toda tupla contém exatamente um valor para cada um de seus atributos;

• Não há ordenação da esquerda pra direita nos componentes de uma tupla. Isso ocorre porque uma tupla é um conjunto de componentes (os valores de atributos), e conjuntos em matemática não possuem ordenação em seus elementos.

• Todo subconjunto de uma tupla é uma tupla.

• O grau de uma tupla varia de 0 – n, onde n é um número inteiro. O grau é dado pela quantidade de atributos que compõem a tupla.

Essa segunda propriedade, a respeito da ordenação dos componentes da tupla, vale somente para o modelo formal. Quando estivermos falando da prática nos SGBDs relacionais, a história será outra. Veremos mais em breve.

Atributos

Agora que você sabe que cada tupla é um conjunto de valores de atributos nomeados, grave que, enquanto as relações representam as entidades do mundo real, os atributos dizem respeito às características dessas entidades.

Assim como as relações, cada atributo de uma relação tem um nome único. Não poderíamos ter duas colunas chamadas “Cidade” em uma mesma relação. Isso traria grandes complicações posteriores para acessar os dados e poderia comprometer a integridade do nosso BD.

Veja os tipos de atributos existentes a seguir:

Atributos multivalorados

Vimos nas propriedades das tuplas que cada valor de atributo em cada tupla deve ser atômico, ou seja, deve carregar exatamente um valor, nem mais, nem menos. Isso está correto e funciona assim mesmo na prática, mas você precisa lembrar que existe também o conceito de atributos multivalorados.

Esses atributos que possuem mais de um valor existem nos bancos de dados relacionais, mas sem quebrar a regra da atomicidade que acabamos de ver. Na prática, a representação de um atributo multivalorado requer que se crie uma tabela auxiliar para guardar os múltiplos valores. Por exemplo, é muito comum que uma pessoa possua mais de um número de telefone, não é? Para representar essa situação, podemos criar a seguinte tabela

“Telefones”, que faz referência à tabela principal “Clientes” através do número de CPF de cada um.

CPFCliente DDD Telefone

123.980.771-15 11 2020-1010 123.980.771-15 11 99123-4567 450.689.123-04 81 3756-4321

Observe que o mesmo cliente (identificado pelo seu CPF) pode possuir mais de um telefone, mas sem que isso quebre a regra da atomicidade. Cada número de telefone está registrado em uma linha diferente dessa tabela auxiliar. Quando precisarmos consultar o(s) número(s) de um cliente, é só procurarmos pelo seu CPF na tabela que serão retornados os números correspondentes. Entendeu?

Atributos compostos

Além dos atributos multivalorados, temos os atributos compostos, que são aqueles que estão espalhados por mais de uma coluna. O exemplo mais comum desse tipo de atributo é o endereço, que costuma estar dividido em partes como logradouro, número, complemento, cidade, etc. Veja que o conjunto dos vários atributos corresponde a uma só informação do mundo real:

CPFCliente Logradouro Número Complemento CEP

204.776.124-22 Av. Paulista 1578 Bloco B 01311-929

450.689.123-04 Av. Cais do Apolo 925 NULL 50030-908

123.980.771-15 Rua Afonso Cavalcanti 455 Sala 10 20211-200

Um atributo pode ser ao mesmo tempo composto e multivalorado, nada impede que isso aconteça. No nosso exemplo de atributo multivalorado, aquele dos números de telefone, se considerarmos o DDD como parte integrante do número, esses dois campos também poderiam ser considerados um atributo composto.

Repare que isso não tem muito efeito prático em um banco de dados, já que os atributos compostos são representados por diversos atributos individuais. Essa classificação é algo mais conceitual, da etapa de modelagem, e é representada no Diagrama Entidade-Relacionamento (DER) através do desmembramento de um atributo em outros.

Mais propriedades

Como você viu, os valores dos atributos em uma relação nunca são vazios. Sempre há exatamente um valor para cada atributo em cada tupla. Para representar os casos onde o valor é desconhecido ou não é aplicável, se utiliza um valor especial chamado NULL (nulo).

No final das contas, é possível afirmar que uma tupla sempre contém o conjunto de todos os atributos presentes na relação, mas que alguns desses atributos podem assumir valores nulos, a depender que foi definido no projeto do BD.

Por fim, ao contrário da ordem das linhas em uma tabela, a ordem das colunas (atributos) em uma tabela é relevante para o banco de dados. Há algumas situações em que essa ordem tem certa influência para o banco, seja na hora de realizar inserções de dados ou questões internas de performance.

Esse último parágrafo pode ter te deixado confuso, já que vimos na seção anterior que o autor C.J. Date diz que não existe ordenação da esquerda para direita nos componentes de uma tupla. Veja que as propriedades do Date dizem respeito ao modelo relacional teórico, que tem seus fundamentos na matemática. Enquanto isso, essa última afirmativa, a de que a ordem tem sim uma certa relevância, diz respeito à prática, em um sistema de bancos de dados relacionais.

Fique atento para essa distinção sutil entre teoria do modelo relacional e prática nos bancos de dados. Caso seja cobrado, observe os elementos do contexto da questão para saber se o examinador está falando da teoria ou da prática e, assim, responder corretamente!

Domínio

Por fim, temos que o domínio é o conjunto de todos os valores atômicos possíveis para um determinado atributo. Por exemplo, em nosso banco de dados, para o nome de cada cliente, o domínio poderia ser o conjunto de cadeias de caracteres de tamanho máximo 100. Veja o exemplo de atributos e seus domínios a seguir:

Atributo Domínio

Nome Cadeias de caracteres de 0 a 100 dígitos Data de Nascimento Datas a partir de 1900

Sexo Caracteres M ou F

No caso do nome, o domínio não seria o conjunto de todos os nomes de pessoas do planeta terra que respeitem aquele tamanho máximo, não é isso. O conceito de domínio está associado às limitações impostas pelo projetista ao banco de dados e não necessariamente a limitações semânticas do mundo real. Dessa forma, a cadeia de caracteres “@#$% 1234 da Silva” poderia ser considerada um nome válido, mesmo que não exista ninguém no mundo que tenha esse nome.

Para compreender bem essas restrições para os valores dos atributos, é importante que você se lembre do conceito de tipo de dados que já citamos anteriormente. O tipo é uma classificação dos dados que define o que o computador “espera” encontrar em uma determinada coluna de uma tabela: valores numéricos (inteiros ou decimais), cadeias de caracteres, bits (valores 0 ou 1), booleano (verdadeiro ou falso), grandes objetos (imagens, arquivos de vídeo...), dentre outros possíveis.

Uma observação importante é que o valor NULL não é parte de nenhum domínio de dados, ou seja, ele não tem tipo. Portanto, ele não é considerado um valor convencional, seja ele zero ou a cadeia de caracteres vazia, mas na verdade um marcador ou placeholder que serve para mostrar que o valor de um determinado campo não se aplica ou está ausente para aquela tupla.

(VUNESP – SEDUC/SP – 2014)

Muitas vezes, não inserimos o valor em um campo de um registro de um banco de dados relacional, por não dispor desse valor ou por não conhecê-lo. Nesse caso, essa ausência de valor é chamada de valor.

a) chave.

b) coringa.

c) morto.

d) nulo.

e) zero.

RESOLUÇÃO:

O valor especial que indica a ausência ou a não aplicabilidade de um valor para um determinado registro de um bacno de dados é chamado de valor nulo (NULL). Esse valor não pertence a nenhum domínio e não tem nenhum tipo de dados, é um mero marcador que indica que não há valor para aquele atributo.

Resposta: D

Chaves

Até aqui, você já foi apresentado às estruturas relacionadas ao armazenamento de dados em um BD relacional e suas características. Mas, conforme vimos na última aula, um banco de dados é uma coleção de dados relacionados

Assim, não basta guardar os dados em tabelas. De modo a se controlar a redundância de dados e manter a integridade do BD, é necessário que se realize a implementação dos relacionamentos entre as diversas tabelas que o compõem. Para possibilitar esses relacionamentos, existem as chaves, que identificam as tuplas e permitem as interconexões entre diferentes tabelas ou até mesmo entre diferentes tuplas de uma mesma tabela.

Como já é de praxe, vamos ilustrar nossa teoria com um exemplo visual para você entender melhor. A seguir trago um pedaço de um modelo lógico bem simplificado de um banco de dados de uma determinada empresa comercial:

Esse trecho de diagrama traz diversos tipos de relacionamento e de chaves. Vamos falar sobre cada um deles a seguir.

Chave Primária

Vamos começar com o conceito mais básico, o de chave primária. Nos modelos lógicos, as chaves primárias costumam estar marcadas com as iniciais PK (Primary Key) ou com um pequeno ícone de chave.

Uma chave primária é uma escolha de um conjunto de atributos que identificam unicamente uma tupla dentro de uma relação. Esse conjunto de atributos pode ser também unitário, caso em que somente um atributo faz o papel de PK. Assim, as chaves primárias podem ser classificadas em simples ou compostas.

Outra característica importante é que a chave primária pode ter correspondência com algum elemento do mundo real, como o CPF, caso em que é considerada uma chave natural. A chave pode também assumir um valor aleatório gerado pelo SGBD, caso em que será chamada de surrogate key, ou chave substituta. O único propósito de uma surrogate key é agir como chave primária, ela não tem correspondência com algum dado do mundo real ou qualquer significado implícito.

No nosso exemplo, idCliente, idSetor, idReunião, etc. são chaves substitutas. Nos projetos de bancos de dados é comum que se nomeie essas chaves substitutas com o prefixo “id”, de “identificação” ou “identificador”.

Essas chaves substitutas muitas vezes são do tipo autoincremento, ou seja, são valores numéricos que vão sendo incrementados pelo próprio SGBD à medida que adicionamos registros. Assim, o usuário não precisa se preocupar com os valores das chaves.

Veja um exemplo:

IdPessoa Nome

1 José Silva Pereira 2 João Silva Pereira 3 Joaquim Silva Pereira ... ...

O campo idPessoa começa no número 1. Quando mais uma pessoa é adicionada, o SGBD atribui o valor da chave como sendo o anterior mais um, ou seja, 1+1 = 2, e assim sucessivamente.

Seja chave natural ou substituta, o que importa mesmo é que o valor da PK seja único dentro de uma mesma tabela, para que possa agir como um identificador. Por consequência disso, temos também que nenhuma chave primária pode assumir o valor NULL.

Ainda a respeito das chaves primárias, quero que você guarde que podem existir campos que contêm restrições de unicidade, que só permitim valores únicos, mas que não são chaves primárias. São campos que contam com a restrição UNIQUE da linguagem SQL.

Uma diferença entre um atributo marcado com UNIQUE e uma PK é que o UNIQUE permite valores nulos, desde que todos os valores válidos sejam diferentes entre si.

Chave Estrangeira

Tome como exemplo a tabela “Venda”. Veja que ela possui um campo chamado CPFVendedor, marcado com FK, e uma seta apontando para a tabela que contém os funcionários do nosso estabelecimento comercial.

Essa marcação FK (Foreign Key) indica que um ou mais atributos da tabela compõem uma chave estrangeira.

Esse tipo de chave identifica unicamente uma tupla em outra tabela ou outra tupla da mesma tabela. A chave estrangeira da tabela de origem referencia a chave primária da tabela de destino, indicando o relacionamento entre as duas tabelas.

No nosso exemplo, veja como cada valor no campo CPFVendedor da tabela Venda faz referência a um registro da tabela Funcionário, indicando que aquele funcionário foi o vendedor que realizou determinada venda:

Atenção !

É importante que você saiba que uma chave estrangeira não necessariamente referencia uma chave primária, apesar de ser o caso mais comum. A chave estrangeira pode referenciar qualquer conjunto de atributos, desde que esses também possam identificar unicamente um registro da tabela de destino.

Por fim, temos que, ao contrário da chave primária, a chave estrangeira pode sim assumir o valor nulo, desde que o projeto defina que a participação da entidade no relacionamento associado não é total. Por exemplo, se um cliente realizasse uma compra online, esta transação não teria um vendedor associado. Assim, o campo CPFVendedor da venda poderia assumir o valor NULL, indicando que o relacionamento não se aplica àquele registro de venda.

(VUNESP – TCE/SP – 2015)

Em um banco de dados relacional, a característica que distingue um atributo A como chave estrangeira de uma tabela R é a seguinte:

a) a tabela R possui apenas esse atributo A.

b) esse atributo A é codificado para maior segurança no acesso à tabela R.

c) esse atributo A é a chave primária de outra tabela T.

d) esse atributo A sempre possui atributo do tipo numérico.

e) todos os demais atributos de R têm o mesmo domínio que o atributo A RESOLUÇÃO:

a) Nada a ver, não existe essa restrição! É possível criar uma tabela que seja composta somente por uma chave estrangeira? A resposta é sim. Mas isso não faz sentido, pois essa tabela não trará nenhuma informação nova, apenas fará referência a uma outra tabela. ERRADA

b) Não é necessário que uma chave estrangeira seja armazenada de forma criptografada! ERRADA

c) Essa é a única alternativa plausível! Embora não seja absolutamente necessário que uma chave estrangeira faça referênca à chave primária de outra tabela, esse geralmente é o caso, já que o registro dessa outra tabela T deve ser referenciado de forma unívoca pela chave estrangeira A. CERTA

d) O atributo da chave estrangeira deve assumir um tipo compatível com o tipo do atributo referenciado da tabela de destino. Esse atributo pode ser numérico, inteiro, decimal... não existe restrição de tipo para as chaves estrangeiras. ERRADA

e) Pode ser o caso, mas também pode não ser. Cada atributo deve ter um domínio compatível com a informação que está sendo representada por ele. O domínio de um atributo de uma tabela não influencia nos domínios dos demais, seja ele chave primária ou estrangeira. ERRADA

Resposta: C

(CESPE – TJ/DFT – 2015)

Julgue o item seguinte a respeito de banco de dados.

Em uma tabela de um banco de dados relacional, se uma restrição de chave primária for definida como composta de mais de uma coluna, os seus valores poderão ser duplicados em uma coluna; no entanto, cada combinação de valores de todas as colunas na definição da restrição de chave primária deve ser exclusiva.

RESOLUÇÃO:

Boa questão! A chave primária tomada por inteiro deve ser sempre única. Contudo, quando temos uma chave primária composta, os atributos que a compõem, individualmente, podem ter valores repetidos.

Gabarito: C

Chave Candidata

As chaves candidatas, ao contrário das primárias e estrangeiras, não são graficamente representadas no modelo lógico. Elas guardam mais relação com o processo de escolha da chave primária na etapa de projeto do BD, já que são, como o nome já diz, meras candidatas a ser chave primária.

As chaves candidatas consistem em atributos ou combinações de atributos que não contêm valores nulos e que servem para identificar unicamente uma tupla – ou seja, têm as mesmas características de uma chave primária. Contudo, elas não foram escolhidas para ser a PK de uma tabela por alguma decisão do projeto.

Na tabela Setor do nosso exemplo, poderíamos considerar o atributo “NomeSetor” como chave candidata, já que provavelmente não há dois setores com o mesmo nome em uma empresa. Contudo, escolhemos a chave substituta idSetor para ser a nossa chave primária.

Relacionamentos

Como já dissemos na aula anterior, temos três possibilidades de cardinalidades para os relacionamentos: 1:1, 1:N e M:N. A maneira com que esses relacionamentos vão ser implementados em um banco de dados relacional vai variar, mas, de modo geral, iremos utilizar chaves estrangeiras e tabelas auxiliares para fazê-lo. Veja:

Um para um (1:1)

Figura: Trecho de um diagrama Entidade-Relacionamento na notação de Chen indicando um relacionamento (1:1)

Nesta cardinalidade, como já sabemos, um registro em uma tabela A só pode referenciar no máximo um registro em outra tabela B e vice-versa. Como exemplo, temos o relacionamento entre Funcionário e Setor.

Observe no diagrama que um funcionário só pode gerenciar um setor e um setor só pode ser gerenciado por no máximo um funcionário.

No nosso caso, poderíamos definir que o atributo CPFGerente, da tabela Setor, é uma chave estrangeira que referencia Funcionário, e que o valor do atributo CPFGerente tem que ser único. Desta maneira, cada Setor só pode ter no máximo um gerente associado e cada funcionário só pode gerenciar no máximo um setor. Veja os exemplos de dados nessas tabelas a seguir:

Funcionário:

CPF Nome

394.036.580-70 Alexandre Silva 713.716.000-07 Marina Almeida 221.621.540-64 Frederico Souza

Setor:

NomeSetor CPFGerente

Vendas 394.036.580-70

Contabilidade 713.716.000-07

Somente criar a chave estrangeira não seria suficiente para definir esse relacionamento como sendo 1:1. Veja que temos também que dizer ao banco de dados que o valor do atributo “CPFGerente” é único na tabela Setor. Se não o fosse, poderíamos ter vários setores com o mesmo gerente. Observe essa situação hipotética:

Setor:

NomeSetor CPFGerente

Vendas 394.036.580-70

Contabilidade 394.036.580-70 Marketing 394.036.580-70

Assim, temos que utilizar uma restrição de unicidade. Dizemos ao SGBD: veja bem, esse atributo CPFGerente não é uma chave primária, mas também não pode ter seus valores repetidos! Na linguagem SQL, vamos criar essa condição ou restrição através do comando UNIQUE.

Um para muitos (1:N):

Figura: Trecho de diagrama Entidade-Relacionamento indicando um relacionamento (1:N)

Nessa cardinalidade, um registro em uma tabela A pode se ligar a múltiplos registros em outra tabela B, mas um registro da tabela B só pode estar associado com um registro da tabela A. O exemplo mais simples desse tipo é o relacionamento entre Venda e Funcionário, através do campo CPFVendedor. Seguindo a lógica, sabemos que

um funcionário pode realizar nenhuma ou diversas vendas, mas uma venda está atribuída somente a um funcionário vendedor.

Esse tipo de relacionamento também pode ser implementado através da inserção de uma chave estrangeira na tabela do lado “muitos”, ou “N”, do relacionamento. Só que dessa vez não precisamos colocar aquela restrição UNIQUE, já que poderá haver vários registros de vendas atribuídos a um mesmo CPF do vendedor. Veja:

Funcionário

CPF Nome

562.099.970-07 Pedro Guimarães 245.494.170-80 Mariana Andrade 221.621.540-64 Frederico Souza

Venda

idVenda CPFVendedor Data/Hora Valor 7555 562.099.970-07 11/10/2018 – 08:45 R$ 450,00 7556 562.099.970-07 11/10/2018 – 09:20 R$ 58,90 3889 562.099.970-07 21/05/2018 – 15:10 R$ 315,20 5943 245.494.170-80 09/07/2018 – 10:55 R$ 980,00

Muitos para muitos (M:N)

Figura: Trecho de diagrama Entidade-Relacionamento indicando um relacionamento (M:N)

Esse tipo de relacionamento é um pouco mais complexo de se implementar. Como o nome já diz, ele ocorre quando um registro de uma tabela pode se referir a vários da outra tabela e vice-versa. Repare no diagrama acima como um relacionamento M:N é representado na modelagem conceitual, indicando que um funcionário pode

participar de várias reuniões, enquanto que uma reunião também pode contar com a participação de diversos funcionários.

Agora veja como os dados ficariam nas tabelas. Destaquei alguns registros para você perceber as repetições.

Em laranja, veja como um funcionário pode participar de múltiplas reuniões, em azul, observe que uma reunião conta com a participação de diversos funcionários.

Funcionário:

CPF Nome

562.099.970-07 Pedro Guimarães 245.494.170-80 Mariana Andrade 221.621.540-64 Frederico Souza 394.036.580-70 Alexandre Silva

713.716.000-07 Marina Almeida

Reunião:

idReunião Data/Hora Sala 120 11/10/2018 – 10:00 204 398 21/05/2018 – 09:30 801 243 09/07/2018 – 13:00 1102

ParticipaReunião:

idReunião CPFFuncionário 120 562.099.970-07

120 245.494.170-80 120 394.036.580-70 398 713.716.000-07 398 245.494.170-80 243 394.036.580-70 243 562.099.970-07 243 713.716.000-07

Essa tabela intermediária que criamos foi chamada de ParticipaReunião no nosso diagrama. Ela é uma tabela auxiliar em que cada registro representa a participação de um funcionário em uma reunião. A chave primária dessas tabelas auxiliares geralmente é representada por uma composição entre as chaves estrangeiras que referenciam as tabelas envolvidas no relacionamento. No nosso caso, idReunião e CPFFuncionário.

Em teoria, relacionamentos de todas as três cardinalidades poderiam ser implementados se utilizando de uma tabela auxiliar como a que acabamos de mostrar. Para representar as outras cardinalidades (1:1 e 1:n), seria necessário somente manipular as restrições de unicidade de valores (UNIQUE) de acordo com o relacionamento. Contudo, não é recomendado que se adote essa abordagem a não ser que seja preciso, já que em alguns casos estaríamos aumentando a redundância de dados e tornando o modelo mais complexo ao adicionar uma tabela sem necessidade.

(CESPE – STJ – 2018)

Acerca de banco de dados, julgue o item que se segue.

Relacionamentos do tipo um-para-um podem ser representados em até três tabelas, de acordo com a obrigatoriedade do relacionamento.

RESOLUÇÃO:

Poder, pode. Só não é recomendado. Relacionamentos 1:1 podem ser representados através de chaves estrangeiras nas tabelas principais, conjugadas com uma restrição de unicidade.

Gabarito: C

Atenção !

Uma instância de um relacionamento é composta por exatamente um elemento de cada entidade participante. É uma ocorrência do relacionamento.

Por exemplo, uma instância do relacionamento ParticipaReunião diz respeito à participação do Funcionário de CPF nº 562.099.970-07 em uma Reunião de id 120.

Essa instância pode ser identificada a partir da conjunção entre as chaves das entidades participantes do relacionamento, ou seja, o idReunião da Reunião X e o CPF de Fulano.

Como sabemos, um relacionamento também pode ter seus próprios atributos. Dessa maneira, poderíamos também incluir algum atributo descritivo que diga respeito ao relacionamento nessa tabela auxiliar, ou seja, que caracterize o evento representado pelo relacionamento, e não as entidades participantes.

Veja um exemplo disso:

idReunião CPFFuncionário Situação 120 562.099.970-07 Presente 120 245.494.170-80 Presente 120 394.036.580-70 Ausente

Autorrelacionamentos

Figura: Trecho de diagrama Entidade-Relacionamento indicando um autorrelacionamento

Na seção que dizia respeito às chaves estrangeiras, você aprendeu que uma FK pode se referir à própria tabela. Isso ocorre quando há um autorrelacionamento, caso em que uma entidade referencia a si mesma. Na prática, isso costuma ocorrer quando há uma determinada hierarquia entre as tuplas da mesma tabela.

O autorrelacionamento está exemplificado no trecho de diagrama lógico acima. O exemplo de chefia é o mais simples desse tipo de relacionamento. Veja que um funcionário tem somente um chefe, mas um chefe pode ter vários funcionários subordinados.

Tanto chefe quanto subordinado são membros da mesma entidade, Funcionário. O relacionamento desse tipo geralmente é implementado adicionando uma chave estrangeira que aponta para a própria chave primária da tabela, assim:

Funcionário:

CPF Nome CPFChefe

562.099.970-07 Pedro Guimarães 245.494.170-80 245.494.170-80 Mariana Andrade 713.716.000-07 221.621.540-64 Frederico Souza 245.494.170-80 394.036.580-70 Alexandre Silva 245.494.170-80

713.716.000-07 Marina Almeida NULL

Como mostramos, o autorrelacionamento do nosso exemplo é de cardinalidade 1:N. Contudo, poderíamos criar um relacionamento deste tipo com cardinalidade 1:1 ou M:N sem problemas. Os autorrelacionamentos, às vezes chamados de relacionamentos recursivos, podem assumir qualquer cardinalidade.

Integridade, Índices, Views e Normalização

Bom, agora que já vimos alguns conceitos básicos dos BDs relacionais, vamos discutir alguns pontos um pouco mais avançados. Mas não se assuste, o grau de cobrança desses conceitos no seu concurso não deve ser tão aprofundado. Leia o conteúdo com atenção e revise quantas vezes achar necessário.

Integridade

Um banco de dados relacional possui um conjunto de restrições de integridade. Essas restrições, como o nome já diz, visam a manter o banco de dados em um estado íntegro, consistente, ao longo de todo o ciclo de vida dos dados.

Essa integridade pode ser física, que diz respeito ao armazenamento dos dados em um meio físico, como em um HD ou fitas de backup (sim, ainda se usam fitas magnéticas como as VHS!). A integridade física pode ser comprometida por corrosão, falhas elétricas, catástrofe natural no local onde os servidores ficam, dentre outras inúmeras possibilidades.

O outro tipo de integridade é a integridade lógica, que é o que realmente interessa para o nosso estudo no momento. A integridade lógica tem a ver com a correção dos dados armazenados e o respeito às regras de negócio definidas quando do projeto do sistema de banco de dados.

Veremos a seguir que há três grandes tipos de restrições de integridade lógica:

Existem na literatura mais dois tipos de integridade que podemos citar:

•Esse tipo de restrição está relacionado com aschaves primárias. A integridade de entidade define que cada chave primária deve ser única e não nula. Também é conhecida como integridade primária ou de chave primária.

Integridade de entidade (entity integrity)

•A integridade referencial é o conceito de chave estrangeira. Ela determina que uma chave estrangeira só pode exisit em dois estados:

•1) Se referindo a uma outra tabela (ou à mesma tabela);

•2) Sendo o valor NULL, caso em que explicitamente estamos dizendo que o relacionamento não existe para determinado registro.

•Ou seja, não é possível que exista uma chave estrangeira que possua um valor diferente de nulo, mas que este valor não tenha correspondência na tabela referenciada. Se a chave estrangeira na tabela A que referencia a tabela B tem o valor “1”, necessariamente deve existir um registro com valor “1” no atributo referenciado da tabela B.

Integridade referencial (referential integrity)

•Muito simples. Você já sabe que o domínio é o conjunto dos valores possíveis para um determinado atributo. Dessa forma, a integridade de domínio determina que os valores de todas as colunas, em todos os registros de um banco de dados fazem parte de seus domínios.

Integridade de domínio (domain integrity)

Ø Integridade de vazio

o Na verdade é um subtipo da integridade de domínio, que determina se os atributos podem ou não assumir valores nulos.

Ø Integridade definida pelo usuário (ou de negócio)

o Diz respeito às regras definidas pelos desenvolvedores do banco de dados que não fazem parte dos três tipos de integridade que apresentamos mais acima.

o Por exemplo, pode-se criar uma regra que diz que, a cada registro adicionado ou removido de uma tabela, será criado um registro em uma tabela de auditoria indicando o que foi adicionado ou removido. Essa tabela de auditoria servirá para controlar quem está fazendo o que no banco de dados.

Índices

Os SGBDs são responsáveis, como você bem sabe, por diversas funcionalidades atribuídas aos sistemas de bancos de dados. Uma dessas atribuições é a de gerenciar a performance do acesso aos dados, permitindo que se trabalhe com tabelas bastante volumosas sem que isso cause uma demora excessiva na realização das tarefas.

Pode ser muito custoso computacionalmente para encontrar o que se deseja em um BD. Grandes organizações possuem bases de dados gigantescas, então é necessário que se organize os registros de alguma maneira para facilitar essa busca.

Imagine que determinada tabela de um banco de dados é uma grande biblioteca, e que, portanto, os dados contidos nesta tabela são os livros. Como você já sabe, as tuplas em uma relação não respeitam uma ordem definida, então os livros nessa biblioteca também estão guardados de forma desordenada. Seria uma tarefa dificílima encontrar qualquer livro nesse local sabendo somente seu título, não é? No pior caso, teríamos que consultar os títulos de todos os livros para encontrar o que estamos procurando por último.

Agora imagine que uma bibliotecária muito zelosa implementa um sistema de classificação dos livros por assunto, criando um documento que indica em quais estantes ficam os livros a respeito de cada matéria. Por sua vez, os títulos dentro de cada assunto passam a ser ordenados por ordem alfabética. Percebeu como encontrar o que queremos ficou mais fácil?

É mais ou menos isso que acontece com os índices em uma tabela. Os índices são estruturas que contêm uma chave de busca e um ponteiro, indicando a localização de determinado bloco de dados dentro da estrutura de armazenamento. A chave de busca é composta por um ou mais atributos de uma tupla, e o ponteiro contém o endereço virtual do bloco de dados onde cada faixa de registros vai estar.

Assim, para dar mais um exemplo, você pode considerar uma empresa que possui uma grande lista de clientes. O administrador de banco de dados verificou que os clientes são frequentemente buscados pelo seu nome e pelo estado onde residem, então ele criou um índice em cima dessas duas colunas. O índice, nessa situação, seria uma estrutura mais ou menos assim:

Chave Ponteiro

Estado: Acre; Nome: Ana Posição 120

Estado: Acre; Nome: Carlos Posição 121

... ...

Estado: Tocantins; Nome: Zelda Posição 850

Tenha em mente que essa é uma simplificação bastante grosseira do que é um índice, mas que o objetivo aqui é somente mostrar a você a lógica de funcionamento dessas estruturas!

Os índices podem assumir diferentes tipos (clustered, non-clustered, primary...), o que diferencia um pouco a maneira como a busca é realizada, mas o propósito geral é o mesmo. Não vamos entrar em detalhes a respeito de cada um, pois o assunto ficaria muito técnico para uma prova que não requer formação específica em TI.

Por fim, guarde que os SGBDs geralmente indexam a chave primária das tabelas automaticamente, pois assume-se que as tuplas serão frequentemente acessadas através desses identificadores únicos.

(CESPE – ANTAQ - 2014)

Acerca de sistemas de gerenciamento de banco de dados relacional (SGBDR), julgue o item a seguir.

A criação de índices, mesmo em tabelas grandes e com atributos pouco esparsos, aumenta as chances de serem obtidas consultas com respostas rápidas.

RESOLUÇÃO:

A questão requer um raciocínio um pouco mais elaborado a respeito de índices. Você lembra que eu citei que os índices apontam para as localizações de determinados blocos de dados, correto? Bom, se os atributos são pouco esparsos, ou seja, estão todos mais ou menos no mesmo bloco, a eficiência do índice é diminuída.

Imagine criar um índice no campo “Sexo” de uma tabela muito grande que contém informações a respeito de Clientes. O atributo em questão só tem as opções “Masculino” ou “Feminino”.

Para uma tabela com milhões de registros, faz pouquíssima diferença organizá-los por sexo, já que cada uma das duas partições vai continuar tendo um volume muito grande de tuplas. Ou seja, a criação do índice não vai facilitar muito nossa vida na hora de encontrar uma tupla específica.

Gabarito: E

Views (visões)

Como você já viu, a estrutura básica dos BDs relacionais é a tabela (relação). Essas tabelas estão persistidas no banco de dados, ou seja, armazenadas de uma forma não volátil, fixa, até que alguém mande um comando

“mandando” alterar ou remover os dados de lá.

Contudo, na maioria das vezes os usuários ou aplicações precisam realizar análises com os dados de uma forma não estática, ou seja, querem visualizar os dados de maneira diferente da forma que estão armazenados lá nas tabelas. Isso diz respeito à característica de suporte a múltiplas visões da abordagem de BD.

Para exemplificar como isso ocorre, vamos trazer um trecho de uma tabela bem simplificada que armazena os alunos de uma escola. Ela segue a seguinte estrutura:

Aluno Dt. Nascimento Turma José 01/10/2004 1ª Ano A Maria 20/02/2006 7ª Série B Pedro 15/06/2003 2º Ano D

... ... ...

Agora imagine que temos esta tabela acima, mas não queremos somente visualizar a lista de alunos, e sim queremos saber quantos estudam em cada turma. Contar manualmente registro a registro qual aluno pertence a qual turma é um trabalho maçante e pode ser quase impossível, dependendo da quantidade de registros na tabela e da frequência com que ela é atualizada.

Para obter o resultado que queremos, poderíamos simplesmente executar a seguinte consulta SQL:

SELECT Turma

,COUNT(Aluno) AS QuantidadeAlunos FROM Alunos

GROUP BY Turma

O resultado, então, seria retornado da seguinte maneira:

Turma QuantidadeAlunos

1ª Ano A 20

1º Ano B 18

2º Ano A 25

... ...

Veja que essa coluna de quantidade de alunos não está explícita em nenhuma tabela, mas foi “criada” por nós no momento em que executamos nossa consulta. Esse resultado não é gravado no banco de dados, somente é exibido para que o usuário realize sua análise ou posteriormente salve em um arquivo, por exemplo.

Continuando com o exemplo, imagine que frequentemente precisamos acessar os dados assim como fizemos nessa consulta acima. Contudo, não é prático que criemos uma nova tabela com essa estrutura diferente, pois estaríamos criando uma redundância desnecessária de dados – a mesma informação estaria representada de formas diferentes em dois locais distintos do banco. Para esses casos, temos as views (visões).

As views são estruturas que podem ser acessadas ilimitadas vezes, possibilitando que reutilizemos as consultas que executamos com frequência. Para criar uma view a partir da consulta mostrada acima, poderíamos rodar o seguinte comando SQL:

CREATE VIEW vw_AlunosPorTurma AS

SELECT Turma

,COUNT(Aluno) AS QuantidadeAlunos FROM Alunos

GROUP BY Turma

Veja que, depois do elemento “AS”, o comando utilizado para criar uma view é idêntico ao que rodamos para realizar nossa consulta que extraiu os dados pela primeira vez – não se preocupe em memorizar esses códigos ainda!

Eu fiz essa observação para mostrar que as views são nada mais que consultas armazenadas.

As views, portanto, são tabelas virtuais. Ou seja, por serem meras consultas salvas, elas não armazenam dados fisicamente no banco de dados. Para fins de consulta posteriores ao banco de dados, contudo, as views são indistinguíveis de tabelas reais, ou seja, pode-se realizar comandos SQL fazendo referência às views como se elas fossem tabelas.

(CESPE – TCE/PE – 2017) A respeito de bancos de dados relacionais, julgue o item subsequente.

Uma visão (view) é derivada de uma ou mais relações e armazena os dados em uma tabela física do banco de dados, visando tornar ágeis as consultas.

RESOLUÇÃO:

Uma view realmente pode ser derivada de uma ou mais relações. Contudo, em via de regra, ela não armazena os dados em uma tabela física, consistido em uma tabela virtual. É somente uma consulta armazenada que pode ser acessada como se fosse uma tabela.

Gabarito: E

Normalização

A normalização foi proposta por Codd em 1970 como sendo parte do modelo relacional. Ela consiste em algumas técnicas utilizadas para eliminar valores não atômicos e redundância de dados. Essas redundâncias, como já discutimos, poderiam causar problemas como a necessidade de manutenção dos mesmos dados em diversas tabelas diferentes, o desperdício de espaço em disco e perda de performance na escrita no banco de dados.

Dessa forma, os objetivos da normalização podem ser sistematizados assim:

1. Reduzir a redundância de dados, organizando as tabelas de modo a facilitar a manutenção, a atualização de dados e a evolução do modelo; e

2. Garantir a integridade dos dados.

A normalização é frequentemente empregada nos bancos de dados relacionais, pois estes costumam servir a aplicações transacionais que lidam com um grande volume de inserções e atualizações de dados. As formas normais são os padrões e regras a respeito da organização das tabelas que fazem parte desse processo.

Essas formas normais são cumulativas, ou seja, para um banco de dados estar na terceira forma normal (3FN), ele também tem que estar na primeira forma normal (1FN) e na segunda (2FN), e assim sucessivamente.

Codd inicialmente propôs essas três formas normais, que são as mais difundidas até hoje nos ambientes de bancos de dados. Assim, um banco de dados pode ser dito normalizado se atende à 3FN.

O modelo posteriormente se expandiu com contribuições de outros especialistas e hoje há uma série de formas de normalização propostas.

Vou transcrever as três primeiras formas normais e explicá-las:

1. Uma tabela está na 1FN somente se todos os seus atributos são atômicos;

Ou seja, seus atributos compostos devem ser desmembrados em suas múltiplas partes, cada uma virando um novo atributo, e os atributos multivalorados representados em uma tabela auxiliar ligada à principal que possua uma linha por registro.

2. Uma tabela está na 2FN somente se está na 1FN e seus atributos não-chave dependam da chave primária inteira. Ou seja, eles não podem depender somente de parte da chave;

Exemplo de violação desta regra:

Fabricante Produto Preço Unitário País Fabricante

Empresa A Bola R$ 15 China

Empresa B Lápis R$ 3 Brasil

Veja que a chave da tabela é composta pelos campos sublinhados Fabricante e Produto. Agora tome o atributo País Fabricante. Esse atributo diz respeito ao fabricante, somente. Não importa qual o produto, desde que o fabricante pertença a determinado país.

Dessa maneira, o atributo “País Fabricante” depende só de parte da chave, a parte do atributo “Fabricante”.

Do ponto de vista desse atributo, a outra parte da chave, composta pelo atributo “Produto”, é absolutamente irrelevante.

3. Uma tabela está na 3FN somente se está na 2FN e nenhum dos seus atributos não-chave apresente dependência funcional em relação a outro atributo não chave.

Exemplo de violação desta regra:

Vendedor Produto Data Qtd. Preço Unitário Valor Total

Vendedor A Bola 10/01/2018 3 R$ 15 R$ 45

Vendedor B Lápis 15/02/2018 10 R$ 3 R$ 30

Veja que o campo “Valor Total” depende de um cálculo de multiplicação entre os campos “Qtd.” e “Preço Unitário”. Dessa forma, o atributo é dependente de outros atributos não-chave.

Podemos dizer que um atributo B apresenta dependência funcional em relação a um atributo (ou conjunto de atributos) A quando o valor de A é capaz de determinar o valor de B. Veja que, no exemplo acima, quando tivermos um valor X para a quantidade e um valor Y para o preço unitário, o valor total vai ser sempre dado pelo cálculo X * Y. Dessa maneira, a informação do valor total é absolutamente redundante no nosso modelo, já que podemos inferi-la através dos valores de outros atributos.

Uma observação que deve ser feita é que a normalização traz uma perda de performance nas consultas, já que cria mais tabelas no modelo, fazendo com que o usuário tenha que realizar múltiplas junções entre tabelas na hora de extrair os dados.

(FCC – DPE/AM – 2018)

Uma tabela de um banco de dados relacional está na primeira forma normal se

a) o número de atributos dessa tabela for limitado pelo sistema gerenciador de banco de dados.

b) os atributos do tipo caractere tiverem comprimento máximo de 30 caracteres.

c) o número de registros dessa tabela for limitado pelo sistema gerenciador de banco de dados.

d) os domínios de todos atributos dessa tabela forem atômicos.

e) os domínios de todos atributos dessa tabela forem compostos por números inteiros.

RESOLUÇÃO:

Para começar, temos que a normalização diz respeito à modelagem formal do banco, não estando presa a regras de SGBDs específicos. Logo, poderíamos eliminar as alternativas a e c. As formas normais não têm nada a ver com tipo de dados ou com tamanho de registros, então as alternativas b e e também estão incorretas.

A primeira forma normal diz que os atributos devem conter exatamente um valor. A assertiva que mais se amolda a esse conceito, por eliminação, é a letra D. Mas veja que a redação está um pouco imprecisa. O domínio dos atributos não vai ser atômico, se fosse assim cada atributo só teria um valor possível. Os domínios são, na verdade, conjuntos de valores atômicos. Ou seja, o domínio é um conjunto com múltiplos valores, esses valores é que devem ser atômicos. Contudo, não vamos brigar com a banca, temos sempre que trabalhar com as opções que nos foram dadas.

Gabarito: D

(FCC – DPE/AM – 2018 - ADAPTADA)

Ao participar de uma reunião sobre Bancos de Dados Relacionais, um Técnico Programador afirmou, corretamente, que

a) o Diagrama de Entidade e Relacionamento, no qual são definidas as chaves primárias e estrangeiras, a normalização, a integridade referencial etc., é essencial para a compreensão do modelo físico de dados.

b) para estar na 2ª Forma Normal, todos os atributos não chaves da tabela do Banco de Dados não devem depender unicamente da chave primária, mas podem depender apenas de parte dela.

c) para deixar uma tabela na 1ª Forma Normal é preciso identificar a sua chave primária, identificar as colunas que têm dados repetidos e removê-las; criar uma nova tabela com a chave primária para armazenar os dados repetidos e criar uma relação entre a tabela principal e a tabela secundária.

RESOLUÇÃO:

a) O diagrama ER faz parte da modelagem conceitual, ou seja, não inclui os conceitos de chaves, normalização ou integridade. Se trocássemos “Diagrama de Entidade e Relacionamento” para “modelo lógico” ou “diagrama lógico”, a resposta estaria correta. ERRADA

b) É exatamente o contrário! Os atributos devem depender da chave por inteiro, ou seja, ter dependência funcional completa em relação à chave. ERRADA

c) A 1FN diz respeito à atomicidade dos atributos. Dessa forma, para implementar um atributo multivalorado em uma tabela normalizada, devemos criar uma nova tabela que possua relacionamento com a tabela principal através de sua chave primária. É essa nossa resposta. CERTA

Gabarito: C

As 12 regras de Codd

E.F. Codd, a primeira pessoa a descrever o modelo relacional, definiu um conjunto de regras que determina as condições necessárias para que um SGBD seja considerado relacional. Foi uma tentativa de Codd para que os diversos fornecedores de bancos de dados não se desviassem do que foi inicialmente proposto por ele como sendo um banco de dados relacional.

Essas regras costumam ser mais cobradas em provas da banca CESPE, mas prudência nunca é demais, então as trouxe para você. Se tiver com muita dificuldade em entendê-las, não se desespere, pois considero um assunto com menor probabilidade de cobrança.

Antes de começar a estudar as regras, quero tranquilizar você. Essas regras foram definidas na década de 80 e muitas delas dizem respeito a situações observadas por Codd nos sistemas de bancos de dados da época. Ao analisá-las fora desse contexto, podemos achar algumas delas confusas e específicas demais. Contudo, não se preocupe! Os examinadores costumam repeti-las quase que na íntegra quando cobram o assunto. Se você se lembrar da ideia geral da regra, mesmo que não seja capaz de explicá-la novamente, você deve conseguir resolver as questões.

Curiosamente, as 12 regras de Codd são 13, já que existe a regra “zero”. Essa regra é um conceito

Regra 0: Para qualquer sistema que seja propagandeado ou nomeado como um SGBD relacional, esse sistema deverá gerenciar bancos de dados exclusivamente através de suas capacidades relacionais.

Essa regra é mais geral, então é mais difícil fazer o “teste” para verificar se determinado SGBD a atende ou não. Para isso, há as 12 regras restantes, que são mais específicas:

Regra 1 – A regra da informação

Todas as informações em um BD relacional são apresentadas logicamente de uma só maneira - como valores em uma tabela.

Isso quer dizer que tudo (mas tudo mesmo) que for armazenado em um SGBD relacional vai ficar em tabelas. Até mesmo os metadados do catálogo ficam em tabelas! O catálogo normalmente é implementado como um banco de dados, tendo suas informações distribuídas em linhas e colunas de tabelas como qualquer outro dado.

Por exemplo, geralmente existe nos SGBDs a tabela Colunas, que armazena informações a respeito dos atributos das diversas tabelas do BD. Simplificando, seria algo assim:

NomeColuna NomeTabela TipoDados PodeNULL

CPF Funcionário int Não

Nome Funcionário varchar Não

NomeDepartamento Departamento Int Não

Regra 2 – A regra do acesso garantido

Todo valor armazenado em um BD relacional pode ser acessado por uma combinação de nome de tabela, valor da chave primária e nome da coluna.

Essa é simples! Veja que os dados nos bancos de dados estão representados em linhas de tabelas. Essas linhas são conjuntos de valores, um para cada atributo ou coluna.

Assim, se soubermos o nome da tabela, a identificação única da linha (que é o valor da chave primária) e o nome da coluna da qual estamos buscando o valor, seremos capazes de extrair qualquer dado do nosso banco de dados relacional.

Regra 3 – Tratamento sistemático dos valores nulos

Os valores nulos (que são diferentes da cadeia de caracteres vazia, do valor zero ou de qualquer outro número) são suportados pelo SGBD Relacional para representar informação ausente ou não aplicável e tratados de uma maneira sistemática, independentemente do tipo de dados.

Regra tranquila! É o que já sabemos a respeito dos valores nulos. Um detalhe é que o desenvolvedor do banco de dados deve ser capaz de “dizer” se cada coluna pode permitir valores nulos ou não, independente do tipo de dados utilizado para a coluna (inteiro, cadeia de caracteres, etc.).

Regra 4 – Catálogo online dinâmico baseado no modelo relacional

A descrição do banco de dados está representada, no nível lógico, da mesma maneira que os dados comuns, para que os usuários autorizados possam aplicar a eles a mesma linguagem relacional que utilizam para os dados normais.

Bom, é o que citamos na regra 1. Se o catálogo está armazenado como um banco de dados normal, nós podemos utilizar a linguagem SQL para fazer consultas sobre ele.

Poderíamos criar consultas que extraem diversas informações do catálogo, como por exemplo quais são as colunas de uma determinada tabela, qual é o tipo de dados mais frequente, qual o total de tabelas do modelo e assim sucessivamente.

Regra 5 – Sublinguagem ampla/compreensiva de dados

O BD relacional pode oferecer suporte a múltiplas linguagens e meios de acesso. Contudo, deve existir pelo menos uma linguagem declarativa bem definida com suporte às seguintes operações:

- Definição de dados - Definição de views - Manipulação de dados - Restrições de integridade - Autorização

- Controle de transações

Essa regra determina que um SGBD pode até ser manipulado por múltiplas linguagens de programação, por meio de interface gráfica ou algum outro modo. Contudo, é necessário que exista pelo menos uma linguagem que englobe todas as funcionalidades listadas acima.

Com o padrão SQL fica fácil atender a essa regra! Essa linguagem, cujo nome é a sigla para Structured Query Language, atende a todos os requisitos descritos.

Regra 6 – Atualização de views

Toda view que é teoricamente atualizável, deve ser também atualizável na prática por meio do sistema.

Essa regra é peculiar. Ela diz mais ou menos o seguinte: se existir uma funcionalidade que permita que o usuário atualize as tabelas que a view consulta se utilizando da própria view, essa funcionalidade deve ser acessível por meio do sistema.

É meio complicada e acredito que tem menos chances de cair na sua prova em relação às demais, então sugiro que você somente memorize o texto da regra (é só uma frase, vai!) se quiser se garantir!

Regra 7 – Inserção, atualização e exclusão de alto nível

A capacidade de gerenciar uma relação base ou uma relação derivada com um só operando se aplica não somente à extração de dados, mas também à inserção, atualização e remoção dos dados.

O texto é um pouco estranho, mas a regra nem tanto. Ela diz que se você é capaz de extrair todos os registros de uma tabela do SGBD fazendo referência apenas ao conjunto dos dados, você também vai poder fazer isso para as operações de inserção, atualização e remoção de dados, sem precisar ir registro a registro.

Vamos explicar de uma forma mais didática. Vamos dizer que um comando SQL, traduzido em linguagem “de gente”, determina o seguinte:

Retorne todos os registros da tabela Funcionário referentes a empregados que moram no estado de PE

Veja que não precisamos dizer ao banco de dados algo como “olhe, traga o funcionário José, a funcionária Maria, o funcionário João, etc.”, não foi? Até porque é improvável que saibamos de cabeça quais são todos os funcionários que moram em Pernambuco...

Dessa maneira, simplesmente “pedimos” ao SGBD que extraia tudo o que existe na tabela e satisfaz à condição de ter o atributo Estado com o valor PE.

Voltando à nossa regra, ela diz o seguinte: se você pode fazer isso com a extração de dados (trabalhar com conjuntos de dados, com a abstração deles), você deve ser capaz de fazer isso também para a inclusão, modificação ou remoção de dados. Assim, você não precisa ir lá no banco de dados e dizer “remova o registro de José, remova o registro de Maria, etc.”. Você pode simplesmente mandar um comando do tipo:

Remova todos os registros da tabela Funcionário referentes a empregados que moram no estado de PE Ou

Altere os telefones de todos os registros da tabela Funcionário referentes a empregados que moram no estado de PE, adicionando “(81)” no começo

Ou mesmo

Adicione à tabela Funcionários_Pernambuco todos os registros da tabela Funcionário referentes a empregados que moram no estado de PE

Entendido? Vamos para a próxima!

Regra 8 – Independência física de dados

Programas de aplicação e atividades terminais não são logicamente afetadas quando mudanças são feitas na representação de armazenamento ou nos métodos de acesso do banco de dados.

Já falamos sobre isso! A independência física diz que você pode alterar detalhes de implementação físicos dos dados, como a maneira que esses dados estão armazenados no disco ou os métodos de acesso internos do SGBD sem que o modelo lógico ou o conceitual (e, por consequência, os programas de aplicação) sejam afetados.

Regra 9 – Independência lógica de dados

Programas de aplicação e atividades terminais não são logicamente afetadas quando mudanças que preservem as informações são realizadas sobre as tabelas.

Essa regra é similar à anterior, mas diz que as alterações no modelo lógico, desde que preservem as informações presentes nas tabelas, não devem afetar as aplicações ou recursos ad hoc.

Regra 10 – Independência de integridade

As restrições de integridade de um banco de dados relacional devem ser definíveis na linguagem relacional e armazenável no catálogo, não nos programas de aplicação.

Essa regra é interessante. Ela diz que as restrições de integridade (que também vimos nesta aula) devem ser gerenciadas pelo SGBD, não pela aplicação. Por exemplo, não é necessário que o sistema de aplicação que utiliza o banco de dados “se preocupe” em gerenciar se as chaves primárias são realmente únicas ou não. O próprio SGBD que vai levantar um erro toda vez que você tentar duplicá-las ou deixar um valor nulo em alguma delas.

Regra 11 – Independência de distribuição

Um SGBD relacional tem independência de distribuição.

Os bancos de dados distribuídos são aqueles cujos dados armazenados em múltiplos locais, sejam múltiplas máquinas no mesmo local físico ou diferentes servidores espalhados por cidades, estados ou até mesmo países diferentes.

A regra diz, basicamente, que a localização física dos dados não deve ser da preocupação do usuário, ou seja, o usuário não enxerga nem é afetado pela localização dos dados. Ele vai simplesmente trabalhar com os dados e executar comandos SQL da mesma maneira que faria se estivessem todos armazenados no mesmo servidor.

Regra 12 – Regra da não subversão ou não transposição

Se um sistema relacional possui uma linguagem de baixo nível (uma linguagem que permite manipular registros individuais), esse baixo nível não pode ser utilizado para subverter ou contornar as restrições de integridade que foram criadas pela linguagem relacional de alto nível (aquela que permite manipular conjuntos de registros de uma vez).

Pode parecer confuso, mas essa regra foi definida porque o problema descrito era comum à época. O que você deve extrair dela é que, mesmo que haja uma outra linguagem no banco de dados, fora a SQL, essa não pode ser utilizada para infringir alguma das restrições de integridade definidas.

(CESPE – SEFAZ/RS – 2019)

Uma das regras de Codd para o modelo relacional consiste a) na independência de distribuição.

b) na presença de uma linguagem de programação no SGBD que promova interface com o banco de dados, com a segurança e com a atualização dos dados.

c) na subversão das regras de integridade ou restrições quando utilizada uma linguagem de baixo nível.

d) no não tratamento das atualizações de visões de dados.

e) na dependência de dados físicos (mudança na memória e no método de acesso).

RESOLUÇÃO:

a) Essa é a 11ª regra! É aquela que define que a localização dos dados em um sistema de armazenamento distribuído deve ser transparente para o usuário, ou seja, ele nem toma conhecimento nem é afetado por ela.

CERTA

b) A regra nº 5 diz que deve haver pelo menos uma sublinguagem compreensiva, declarativa e bem definida que tenha as seguintes funcionalidades:

- Definição de dados - Definição de views - Manipulação de dados - Restrições de integridade - Autorização

- Controle de transações

Assim, vemos que os requisitos são um pouco distintos dos mostrados pelo examinador. ERRDA

c) Na verdade, a 12ª regra de Codd prega justamente a não subversão das restrições de integridade quando utilizada uma linguagem de baixo nível. ERRADA

d) É justamente o contrário! A 6ª regra determina que todas as views que foram teoricamente atualizáveis, também serão atualizáveis na prática pelo sistema. ERRADA

e) A regra nº 8 diz respeito à independência física de dados. Os programas de aplicação não são afetados por mudanças na memória ou em métodos de acesso. ERRADA

Gabarito: A

* * *

Ficamos por aqui com nossa teoria! Como sempre, trago a seguir questões recentes de diversas bancas e seus comentários.

Bons estudos!

Questões comentadas pelo professor

1.

Um dos conceitos básicos da modelagem de bancos de dados relacionais são as chaves primárias, sobre as quais, é correto afirmar que

a) devem ser compostas por, pelo menos, dois atributos.

b) em cada banco de dados deve haver uma tabela que armazena as chaves primárias de todas as demais tabelas.

c) devem ser armazenadas, de forma redundante, em pelo menos duas tabelas distintas do banco de dados.

d) não podem ser formadas por nomes próprios.

e) podem ser formadas tanto por atributos numéricos, quanto por atributos literais.

RESOLUÇÃO:

a) As chaves primárias podem ser compostas por dois ou mais atributos, mas também podem ser compostas por um só, caso em que são chamadas de chaves primárias simples. ERRADA

b) Não há esse requisito nos bancos de dados relacionais. Cada chave primária é armazenada em sua própria tabela, pois é um atributo ou conjunto de atributos daquela tabela. O que se armazena em um local específico (o catálogo) no banco de dados são os metadados, que dizem quais são os atributos que compõem a chave primária de cada tabela. Contudo, os valores das chaves em si não fazem parte desses metadados. ERRADA

c) Essa restrição também não existe! As chaves primárias são compostas por um ou mais atributos de uma tabela e seus valores não se repetem dentro desta tabela, nem podem assumir o valor nulo. Não é necessário que esses dados estejam armazenados de forma redundante. ERRADA

d) Desde que esses nomes possam identificar unicamente o objeto sendo representado na tabela, não há empecilho. Por exemplo, se temos uma tabela que contém todos os países do mundo, podemos identificá-los unicamente pelos seus nomes sem problema algum. ERRADA

e) Essa é a resposta correta. O requisito para a chave primária é que ela assuma valores únicos e não nulos. Dessa maneira, não importa se elas são numéricas ou literais. CERTA

Resposta: E

2.

Considerando bancos de dados relacionais, no modelo relacional há os conceitos de chaves candidata, primária e estrangeira, sobre os quais é correto afirmar que uma

a) chave estrangeira deve ser criptografada.

b) chave estrangeira deve ser do tipo simples (ter apenas um atributo).

c) chave primária deve ser do tipo autoincremento.

d) chave primária deve ser do tipo composto (ter mais de um atributo).

e) relação pode ter mais de uma chave candidata.