Mecanismo formal para analisar esquemas de relações baseado nas suas chaves e nas dependências funcionais entre seus atributos.
A normalização de dados é uma série de passos que se segue no projeto de um banco de dados que permite um armazenamento consistente e um eficiente acesso aos dados em um banco de dados relacional. Esses passos reduzem a redundância de dados e as chances dos dados se tornarem inconsistentes. A abreviação usada, (NF), vem do inglês, “Normal Form”.
O processo de normalização aplica uma série de regras sobre as tabelas (também chamadas de relações) de um banco de dados, para verificar se estão corretamente projetadas.
No entanto, muitas SGBDs relacionais não têm separação suficiente entre o projeto lógico da base de dados e a implementação física do banco de dados, e isso tem como consequência que as consultas feitas a um banco de dados totalmente normalizado têm um mau desempenho. Nestes casos, usa-se por vezes a desnormalização para melhorar o desempenho, com o custo de menores garantias de consistência.
Uma regra de ouro que devemos observar quando do projeto de um Banco de Dados baseado no Modelo Relacional de Dados é a de “não misturar assuntos em uma mesma Tabela”. Por exemplo: na Tabela Clientes devemos colocar somente campos relacionados com o assunto Clientes. Não devemos misturar campos relacionados com outros assuntos, tais como Pedidos, Produtos, etc. Essa “Mistura de Assuntos” em uma mesma tabela acaba por gerar repetição desnecessária dos dados bem como inconsistência dos dados.
Normalmente após a aplicação das regras de normalização de dados, algumas tabelas acabam sendo divididas em duas ou mais tabelas, o que no final gera um número maior de tabelas do que o originalmente existente. Este processo causa a simplificação dos atributos de uma tabela, colaborando significativamente para a estabilidade do modelo de dados, reduzindo-se consideravelmente as necessidades de manutenção.
O objetivo da normalização não é evitar JOINs, nem melhorar performance do banco de dados. Na verdade ele até aumenta o problema em relação aos dois itens. O objetivo real da normalização é evitar anomalias de inserção, deleção e atualização.
Normalização é uma Ferramenta para Validação da Qualidade de um Esquema.
As formas normais até FNBC são baseadas em dependências funcionais, exceto a 1FN, que faz parte da definição do modelo relacional.
O design conceitual baseado no modelo ER tende naturalmente a produzir esquemas normalizados, a menos da 1FN. A separação de conceitos é o resultado natural do design conceitual bem feito. Na prática, esquemas que violam a normalização são exemplos de esquemas mal projetados.
A utilidade prática da 4FN e 5FN é limitada, porque num banco de dados real com muitos atributos, é muito difícil (e praticamente irrelevante) descobrir tais dependências e restrições.
São objetivos do processo de normalização:
Reduzir redundâncias.
Evitar anomalias de atualização.
Simplificar imposição de restrições de integridade, com a redução de redundâncias, se torna mais fácil impor restrição de integridade.
Produzir uma boa base para crescimento futuro. O modelo normalizado é escalável.
Relações não normalizadas são sujeitas a anomalias durante as atualizações:
Anomalias de inserção: Inserir empregado requer repetir dados de departamento.
Anomalias de exclusão: Excluir único empregado de departamento também exclui o departamento.
Anomalias de modificação: Mudar gerente de departamento requer modificar várias tuplas.
Origem
Um percentual significativo dos sistemas de informação hoje usados foram desenvolvidos ao longo dos últimos vinte anos e não utilizam bancos de dados relacionais. São os chamados sistemas legados (“Legacy Systems”). Os dados destes sistemas estão armazenados em arquivos de linguagens de terceira geração, como Basic, COBOL, MUMPS e outras, ou então em bancos de dados da era pré-relacional, como IMS, ADABAS, DMS-II e os SGBD do tipo CODASYL (IDMS, IDS/2,…). Raramente, os arquivos destes sistemas estão documentados através de modelos conceituais. Além disso, muitos dos bancos de dados relacionais existentes, principalmente em microcomputadores, não possuem documentação na forma de modelo conceitual.
Com a tentativa de migrar estes sistemas para uma nova plataforma tecnológica, ou para realizar a manutenção dos mesmos softwares. Passou a existir a necessidade conseguir gerar o modelo conceitual dos dados destes sistemas.
Um exemplo é a manutenção rotineira de software de um sistema de informações. Neste caso, o modelo conceitual pode ser usado como documentação abstrata dos dados durante discussões entre usuários, analistas e programadores. A existência de um modelo conceitual permite que pessoas que não conheçam o sistema possam aprender mais rapidamente o seu funcionamento.
Outro exemplo no qual é importante possuir o modelo conceitual de um banco de dados já implementado é o da migração do banco de dados para uma nova plataforma de implementação. Por exemplo, usando um SGBD relacional. A disponibilidade de uma documentação abstrata, na forma de um modelo conceitual dos dados do sistema existente, pode acelerar em muito o processo de migração, pois permite encurtar a etapa de modelagem de dados do novo banco de dados.
Para obter este modelo conceitual, é necessário a utilização de engenharia reversa em saídas de dados destes sistemas legados, geralmente relatórios (um arquivo contendo informações). E a partir destes arquivos tentava-se realizar a engenharia reversa.
O primeiro passo é a representação da descrição de cada arquivo existente na forma de um esquema de uma tabela relacional não normalizada. Este primeiro passo objetiva obter uma descrição independente do tipo de arquivo que está sendo utilizado. A partir daí, o processo trabalha apenas com tabelas relacionais, o que o torna independente do tipo de arquivo que está sendo usado como entrada ao processo de normalização.
1º Forma Normal (1FN)
É parte da definição formal de uma relação. Foi definida para não permitir atributos multivalorados, atributos compostos e suas combinações.
Um esquema de relação R está na 1FN se todos os seus atributos forem atômicos (simples e monovalorados), ou seja, não são permitidos atributos multivalorados, atributos compostos ou atributos multivalorados compostos. Uma tabela está na 1FN, se e somente se, não contiver tabelas aninhadas.
Um atributo que representa uma abstração de outros atributos é do tipo Composto. Atributos Atômicos também são conhecidos como Atributos Escalares.
Observação: O Peter Chen no modelo conceitual prevê o uso do atributo multivalorado (telefone = telefone1, telefone2, telefone3). Então quando deseja se converter em uma tabela no modelo relacional, será necessário normalizar esta tabela.
Observação: Atributo composto é a utilização de um campo para armazenagem de diversas informações. Por exemplo: Endereços contendo bairro, rua, etc. este problema é solucionado realizando a decomposição do campo em vários campos.
Por definição, toda tabela já está na tabela normal. Mas na prática não é bem assim.
Exemplo de Tabela que não está na 1FN, devido ao campo Localização que é multivalorado. Ou seja, provocando uma tabela aninhada.
A solução para este problema é remover a tabela aninhada “Local” de dentro da tabela departamento:
Existem algumas representações, que podem identificar que existe uma relação dentro de uma relação (tabelas aninhadas), o que demonstra não estar na 1FN
Exemplo:
FUNCIONÁRIOS = {CODFUNC + NOME + CARGO + {PROJETO + DATAINI + DATA FIM}}
ou
FUNCIONÁRIOS = (CODFUNC + NOME + CARGO + (PROJETO + DATAINI + DATA FIM))
Para colocar na 1FN:
FUNCIONÁRIOS = {CODFUNC + NOME + CARGO}
FUNC_PROJ = {CODFUNC + PROJETO + DATAINI + DATA FIM}
OBS: A chave primária de “Funcionários” será chave estrangeira de FUNC_PROJ.
O exemplo abaixo exibe outro problema, o nome “Telefones” como está no plural indica um campo composto, o que vai contra a 1FN (considerando que o campo TELEFONES é multivalorado):
PESSOAS = {ID + NOME + ENDERECO + TELEFONES}
Para deixar esta tabela na 1FN, deve-se separar o campo multivalorado TELEFONES em uma tabela adicional, desta forma:
PESSOAS = {ID + NOME + ENDERECO}
TELEFONES = {PESSOA_ID + TELEFONE}
Outra forma de identificar se a tabela está na 1NF é verificando se existem tabelas aninhadas, ou seja, mais de um registro para uma chave primária.
Dependência Funcional
Em uma tabela relacional, diz-se que uma coluna C2 depende funcionalmente de uma coluna C1 (ou que uma coluna C1 determina a coluna C2) quando, em todas as linhas da tabela, para cada valor de C1 que aparece na tabela, aparece o mesmo valor de C2.
C1 → C2
C1 determina a coluna C2
C2 depende funcionalmente de C1
A dependência Funcional (DF) deve ser explicitamente definida por alguém que conheça a semântica dos atributos de uma relação.
Ou seja, Para C1 determinar C2 sempre que eu ver o valor de C1 eu já saberei o valor de C2. Digamos que CPF seja C1, e nome C2. Toda vez que CPF tiver o valor “111” nós já sabemos que C2 será “Ana”; toda vez que C1 for “555”, sabemos que C2 será “João”. Podemos dizer que C1 (CPF) determina C2 (Nome), ou que C2 (Nome) depende funcionalmente de C1 (CPF).
Com os dados acima, percebemos que é possível fazer o inverso, que a partir de C2 também podemos saber quem é C1, o que nos leva a uma lição. Para determinar a dependência funcional, não pode ser considerado um pequeno conjunto de ocorrências em uma tabela. É necessário o conjunto mais amplo possível, para que não seja passada uma falsa ideia.
Sempre que eu vejo Ana, eu sei que o CPF será 111?
Estendendo o número de dados, é possível visualizar melhor, chegando a conclusão de que apenas a partir de CPF podemos saber qual o nome, ou seja CPF → Nome (CPF determina Nome, ou Nome é dependente funcional de CPF).
O objetivo é descobrir qual campo será a chave primária da tabela.
2ª Forma Normal (2FN): Não Parciais
“Uma relação encontra-se na 2FN se e somente se estiver em 1FN e não contém dependências parciais.”
Dependência Parcial: ocorre quando uma coluna depende apenas de uma parte de uma chave primária composta.
Na tabela abaixo, que não está na segunda forma normal, percebemos as Dependências funcionais dos campos.
Na tabela a cima é possível visualizar que temos dados de 2 entidades diferentes, pois alguns campos dependem funcionalmente de CPF, e outros dependem do campo Numéro do Projeto. Para ficar na 2FN a tabela acima seria convertida em:
3ª Forma Normal (3FN): Não Transitivas
“Uma relação está em 3FN se e somente se estiver em 2FN e nenhum atributo não-primo (isto é, que não seja membro de uma chave) for transitivamente dependente da chave primária.”
Ou seja, para estar na 3ª forma normal não pode haver dependência funcional transitiva.
A relação não deve ter um atributo não-chave funcionalmente determinado por um outro atributo não-chave(ou por um conjunto de atributos não-chave).
Dependência Transitiva: ocorre quando uma coluna, além de depender da chave primária de uma tabela, depende de outra coluna ou conjunto de colunas da tabela.
Como podemos perceber “Num-Dept” é dependente funcional de CPF. Nome-Dept e Ger-Dept são dependentes funcionais de “Num-Dept”, logo eles ocorre uma dependência transitiva de Nome-dept e Ger-Dept com CPF. E na 3FN isso não pode ocorrer.
Para solucionar este problema, divide-se em duas tabelas:
Uma tabela está na terceira forma normal (3FN) se estiver na 2FN e não possuir dependências transitivas, ou indiretas. Uma dependência transitiva ocorre quando A -> B e B -> C, então A -> C. Em outras palavras, deve-se evitar que qualquer atributo não-chave seja dependente funcional de outro atributo não-chave.
Observe o exemplo:
Considere um Pedido número 00001, para este pedido se observarmos o formulário em papel teremos muitos campos a considerar, contudo usaremos apenas alguns para facilitar o entendimento.
PEDIDOS = {CD_PEDIDO + CLIENTE + VENDEDOR + ATENDENTE + PRODUTO + QUANT + VALOR}
Neste momento devemos idealizar o pedido número: 00001 e efetuar os seguintes testes:
Cd_Pedido
Cliente
Vendedor
Atendente
Produto
Qntd.
Valor
00001
“Douglas Tybel”
“Marco”
“João”
“Tenis”
“1”
“50.00”
00001
“Douglas Tybel”
“Marco”
“João”
“Sandália”
“2”
“80.00”
00001
“Douglas Tybel”
“Marco”
“João”
“Carteira”
“1”
“35.00”
Observe que temos uma Dependência Funcional Transitiva, pois Quantidade e Valor dependem de produto, e este depende do código do pedido.
Aplicando a 3FN, teremos:
Cd_Pedido
Cliente
Vendedor
Atendente
00001
“Douglas Tybel”
“Marco”
“João”
00001
“Douglas Tybel”
“Marco”
“João”
00001
“Douglas Tybel”
“Marco”
“João”
Cd_Pedido
Produto
Qntd.
Valor
00001
“Tenis”
“1”
“50.00”
00001
“Sandália”
“2”
“80.00”
00001
“Carteira”
“1”
“35.00”
Forma Normal Boyce-Codd (BCNF): Dependência apenas da Superchave
O conceito de normalização foi introduzido por E. F. Codd em 1972. Inicialmente Codd criou as três primeiras formas de normalização chamando-as de: primeira forma normal (1NF), segunda forma normal (2NF) e terceira forma normal (3NF). Uma definição mais forte da 3NF foi proposta depois por Boyce-Codd, e é conhecida como forma normal de Boyce-Codd (FNBC).
É uma forma mais restritiva de 3FN, isto é toda relação em FNBC está também em 3FN; entretanto, uma relação em 3FN não está necessariamente em FNBC.
“Uma relação está em FNBC se para toda df X → Z, X é uma Superchave.”
Uma Superchave SK especifica uma restrição de unicidade de que duas tuplas distintas em um estado r de R não podem possuir o mesmo valor para SK.
Chave primária é a Superchave mínima.
A BCNF diz que todo elemento deve depender apenas de uma chave.
Df2: {Professor} → { Disciplina}, porém {Professor} não é uma Superchave.
Devido a este problema, poderá ocorrer uma anomalia de exclusão: se Carlos sair da aula de Física, não teremos nenhum registro de que Antonio leciona Física.
A solução para este problema é a criação de duas tabelas:
Definição que engloba as outras formas normais, e define que uma tabela está em BCNF se, e somente se, todo determinante funcional for em relação a uma chave candidata.
Na prática, uma tabela está em BCNF se estiver em 3NF e não existir dependência funcional dentro da chave primária.
Ou seja, se todos os atributos são funcionalmente dependentes da chave, de toda a chave e nada mais do que a chave. Ou, em outras palavras, todos os determinantes são chaves candidatas.
Um modelo que está em BCNF está pronto para ser implementado numa arquitetura de banco de dados relacional.
4ª Forma Normal (4FN)
“Uma relação está em 4ª Forma Normal (4FN) se, e somente se, estiver na 3FN e não contiver dependências multivaloradas.”
Dada uma relação qualquer com três atributos x, y e z, diz-se que y depende de forma multivalorada de x se e somente se sempre que existirem duas tuplas (x1,y1,z1) e (x1,y2,z2) existirão também duas tuplas (x1,y1,z2) e (x1,y2,z1).
Refere-se à combinação de valores de atributos multivalorados disjuntos (y e z).
x na verdade, relaciona-se com y e com z de forma independente.
5ª Forma Normal (4FN)
“Uma relação R está na 5FN , também chamada de forma normalizada de projeção-junção (PJ/NF) se, e somente se, toda dependência de junção em R for consequência de chaves candidatas de R.”
As DM são uma tentativa de detectar decomposições sem perdas que se apliquem a todas as relações de um dado esquema.
Se não é possível reconhecer qualquer DM em R, não existe decomposição sem perdas em duas relações.
Existem relações que não podem ser decompostas em duas projeções sem perda, mas podem ser decompostas em três ou mais. Estas relações podem ser descritas como “decomponível n” (n>2) (Date), significando que a relação em questão pode ser decomposta sem perda em n projeções, mas não em m projeções, m < n.
Esta limitação é denominada dependência de junção (DJ).
Uma relação R satisfaz a dependência de junção * (X, Y, …Z) se, e somente se, R for igual à junção de suas projeções em X, Y, …Z, onde X, Y, …Z forem subconjuntos do conjunto de atributos de R.
Resolução de Questões de Concursos Anteriores
TRT 11ª Região – Analista Judiciário – 2011 – FCC
Considere:
I. Regra 1 – Todas as informações são representadas de forma explícita no nível lógico e exatamente em apenas uma forma, por valores em tabelas.
II. Regra 2 – Cada um e qualquer valor atômico (datum) possui a garantia de ser logicamente acessado pela combinação do nome da tabela, do valor da chave primária e do nome da coluna.
III. Regra 3 – Valores nulos não devem ser utilizados de forma sistemática, independente do tipo de dado ainda que para representar informações inexistentes e informações inaplicáveis.
Das regras de Codd para bancos de dados relacionais, está correto o que consta em
a) I, apenas.
b) II, apenas.
c) I e II, apenas.
d) II e III, apenas.
e) I, II e III.
RESPOSTA: C
As Regras de Codd são:
Um banco de dados, para que seja considerado “totalmente relacional”, deve atender as 12 regras definidas por E. F. Codd, o criador do modelo relacional para banco de dados.
As doze regras de Codd estão baseadas na regra zero, que determina o seguinte: “Qualquer sistema considerado, ou que deseja ser, um sistema gerenciador de banco de dados relacional deve ser capaz de gerenciar, por completo, bases de dados através de sua capacidade relacional”. Essa regra determina que um SGBDR não permite exceções quanto ao modelo relacional de gerenciamento de bases de dados.
As 12 Regras são as seguintes:
Regra 1 – Representação de valores em tabelas: Todas as informações do BD relacional são representadas de forma explícita no nível lógico e exatamente em apenas uma forma – por valores em tabelas.
Regra 2 – Acesso Garantido: Cada um e qualquer valor atômico (datum) em um banco de dados relacional possui a garantia de ser logicamente acessado pela combinação do nome da tabela, do valor da chave primária e do nome da coluna.
Regra 3 – Tratamento sistemático de nulos: Valores nulos devem ser suportados de forma sistemática e independente do tipo de dado para representar informações inexistentes e/ou inaplicáveis.
Regra 4 – Dicionário de dados ativo baseado no modelo relacional: A descrição do banco de dados é representada no nível lógico da mesma forma que os dados ordinários, permitindo que usuários autorizados utilizem a mesma linguagem relacional aplicada aos dados regulares.
Regra 5 – Linguagem Detalhada: Um sistema relacional pode suportar várias linguagens e várias formas de recuperação de informações. Entretanto, deve haver pelo menos uma linguagem, com uma sintaxe bem definida e expressa por conjuntos de caracteres, que suporte de forma compreensiva todos os seguintes itens: definição de dados, definição de views, manipulação de dados (interativa e embutida em programas), restrições de integridade, autorizações e limites de transações.
Regra 6 – Atualização de Views: Todas as visões (“views”) que são teoricamente atualizáveis devem também ser atualizáveis pelo sistema.
Regra 7 – Atualização de alto nível: A capacidade de manipular um conjunto de dados (relação) por meio de um simples comando deve-se estender às operações de inclusão, alteração ou exclusão de dados.
Regra 8 – Independência Física: Programas de aplicação permanecem logicamente inalterados quando ocorrem mudanças no método de acesso ou na forma de armazenamento físico.
Regra 9 – Independência Lógica: Mudanças nas relações e nas views provocam pouco ou nenhum impacto nas aplicações.
Regra 10 – Independência de Integridade: As aplicações não são afetadas quando ocorrem mudanças nas restrições de integridade.
Regra 11 – Independência de Distribuição: As aplicações não são logicamente afetadas quando ocorrem mudanças geográficas dos dados. Devem permanecer inalterados quando são distribuídos em meios ou máquinas diferentes.
Regra 12 – Não Subversão: Se um sistema possui uma linguagem de baixo nível, essa linguagem não pode ser usada para subverter as regras de integridades e restrições definidas no nível mais alto.
Além dessas doze regras básicas, o modelo relacional também define nove regras estruturais que tratam da definição de chaves primárias, chaves estrangeiras, views, tabelas etc.; dezoito regras de manipulação que definem as operações de “join”, “union”, “division” etc.; e três regras de integridade: integridade de entidade, integridade referencial e a capacidade de definir outras regras de integridade sem introduzir dependência estrutural. A integridade de entidade define que uma chave primária não pode ter valores duplicados ou nulos.
A integridade referencial determina que o valor de uma chave estrangeira deve ter obrigatoriamente correspondência em uma chave primária de uma outra relação.
TCE-PR – Analista de Controle – 2011 – FCC
Considere a situação expressa pelas seguintes relações: um cliente faz n pedidos mas um pedido específico é de somente um cliente. Seguindo, em um pedido específico são relacionados n produtos mas um mesmo produto pode constar em mais de um pedido. Após normalizar essas relações é possível que se estabeleçam tabelas relacionais correspondentes, sendo elas
a) cliente, pedido e produto.
b) cliente, cliente-pedido e produto.
c) cliente, pedido, pedido-produto e produto.
d) pedido-produto e cliente-produto.
e) pedido, pedido-produto e cliente-produto.
RESPOSTA: C
CLIENTE X PEDIDO (1:N)
PEDIDO X PRODUTOS (N:N)
Após a normalização:
CLIENTE X PEDIDO (1:N)
PEDIDO X PEDIDO_PRODUTOS (1:N)
PRODUTOS X PEDIDO_PRODUTOS (1:N)
TRT 4ª Região – Técnico Judiciário – 2011 – FCC
No contexto de banco de dados relacional, das 12 regras definidas por Codd, aquela que determina que os programas de aplicação e as operações interativas devem permanecer logicamente inalteradas, quaisquer que sejam as trocas efetuadas nas representações de armazenamento e métodos de acesso, chama-se independência
a) lógica dos dados.
b) física dos dados.
c) de acesso.
d) de integridade.
e) de distribuição.
RESPOSTA: B
As Regras de Codd são:
Um banco de dados, para que seja considerado “totalmente relacional”, deve atender as 12 regras definidas por E. F. Codd, o criador do modelo relacional para banco de dados.
As doze regras de Codd estão baseadas na regra zero, que determina o seguinte: “Qualquer sistema considerado, ou que deseja ser, um sistema gerenciador de banco de dados relacional deve ser capaz de gerenciar, por completo, bases de dados através de sua capacidade relacional”. Essa regra determina que um SGBDR não permite exceções quanto ao modelo relacional de gerenciamento de bases de dados.
As 12 Regras são as seguintes:
Regra 1 – Representação de valores em tabelas: Todas informações do BD relacional são representadas de forma explícita no nível lógico e exatamente em apenas uma forma – por valores em tabelas.
Regra 2 – Acesso Garantido: Cada um e qualquer valor atômico (datum) em um banco de dados relacional possui a garantia de ser logicamente acessado pela combinação do nome da tabela, do valor da chave primária e do nome da coluna.
Regra 3 – Tratamento sistemático de nulos: Valores nulos devem ser suportados de forma sistemática e independente do tipo de dado para representar informações inexistentes e/ou inaplicáveis.
Regra 4 – Dicionário de dados ativo baseado no modelo relacional: A descrição do banco de dados é representada no nível lógico da mesma forma que os dados ordinários, permitindo que usuários autorizados utilizem a mesma linguagem relacional aplicada aos dados regulares.
Regra 5 – Linguagem Detalhada: Um sistema relacional pode suportar várias linguagens e várias formas de recuperação de informações. Entretanto, deve haver pelo menos uma linguagem, com uma sintaxe bem definida e expressa por conjuntos de caracteres, que suporte de forma compreensiva todos os seguintes itens: definição de dados, definição de views, manipulação de dados (interativa e embutida em programas), restrições de integridade, autorizações e limites de transações.
Regra 6 – Atualização de Views: Todas as visões (“views”) que são teoricamente atualizáveis devem também ser atualizáveis pelo sistema.
Regra 7 – Atualização de alto nível: A capacidade de manipular um conjunto de dados (relação) por meio de um simples comando deve-se estender às operações de inclusão, alteração ou exclusão de dados.
Regra 8 – Independência Física: Programas de aplicação permanecem logicamente inalterados quando ocorrem mudanças no método de acesso ou na forma de armazenamento físico.
Regra 9 – Independência Lógica: Mudanças nas relações e nas views provocam pouco ou nenhum impacto nas aplicações.
Regra 10 – Independência de Integridade: As aplicações não são afetadas quando ocorrem mudanças nas restrições de integridade.
Regra 11 – Independência de Distribuição: As aplicações não são logicamente afetadas quando ocorrem mudanças geográficas dos dados. Devem permanecer inalterados quando são distribuídos em meios ou máquinas diferentes.
Regra 12 – Não Subversão: Se um sistema possui uma linguagem de baixo nível, essa linguagem não pode ser usada para subverter as regras de integridades e restrições definidas no nível mais alto.
Além dessas doze regras básicas, o modelo relacional também define nove regras estruturais que tratam da definição de chaves primárias, chaves estrangeiras, views, tabelas etc.; dezoito regras de manipulação que definem as operações de “join”, “union”, “division” etc.; e três regras de integridade: integridade de entidade, integridade referencial e a capacidade de definir outras regras de integridade sem introduzir dependência estrutural. A integridade de entidade define que uma chave primária não pode ter valores duplicados ou nulos.
A integridade referencial determina que o valor de uma chave estrangeira deve ter obrigatoriamente correspondência em uma chave primária de uma outra relação.
TRT 23ª Região – Técnico Judiciário – 2011 – FCC
No contexto de normalização, quando a tabela não contém tabelas aninhadas e não possui colunas multivaloradas; não contém dependências parciais, embora contenha dependências transitivas, diz-se que ela está na
a) primeira forma normal (1FN).
b) segunda forma normal (2FN).
c) terceira forma normal (3FN).
d) quarta forma normal (4FN).
e) quinta forma normal (5FN).
RESPOSTA: B
Se ela não contivesse dependências transitivas estaria na 3ª Forma Normal.
TRT 08ª Região – Analista Judiciário – 2010 – FCC
Considere um formulário eletrônico de pedidos onde conste o código e o nome do cliente que faz o pedido; o número e a data do pedido; e a lista de produtos pedidos contendo o código do produto, o nome do produto, a quantidade pedida do produto e o valor unitário do produto. Todos os dados serão persistidos em um SGBD relacional, com exceção dos totais. Todos os códigos são identificadores únicos.
No modelo E-R não normalizado, o relacionamento entre Pedido e Produto (considere o vetor no sentido Pedido-Produto) é do tipo
A) entidade associativa.
B) entidade fraca.
C) 1:n.
D) n:m.
E) n:1.
RESPOSTA: D
Porém acredito que o correto seria C. Essa questão está correta como “N:M”?
Pelo formulário teríamos uma entidade única:
Pedido (Código do cliente, Nome do Cliente, Numero do Pedido, Data do Pedido, Produto (Código do Produto, Nome do Produto, Quantidade PEDIDA do Produto, Valor do Produto)).
Dessa forma, produto seria apenas um atributo multivalorado. Mas como na questão ele fala do relacionamento entre as duas entidades, poderíamos decompor em 2 entidades:
Pedido (Código do cliente, Nome do Cliente, Número do Pedido, Data do Pedido).
Produto (Código do Produto, Nome do Produto, Quantidade PEDIDA do Produto, Valor do Produto).
Observe que a questão fala de N:M, mas dessa forma não funcionaria … Pois quando falamos Quantidade PEDIDA do produto…
Obrigatoriamente temos uma relação 1:N, pois se fosse N para M, estaríamos dizendo que qualquer pedido daquele produto todos teriam que pedir a mesma quantidade. E caso queira deslocar o campo Quantidade PEDIDA do PRODUTO para a entidade Pedido, estaríamos dizendo que todos os produtos pedidos em um item deveriam ser pedidos da mesma quantidade.
Logo o correto seria 1:N (Pedido – Produto)
Pedido (Código do cliente, Nome do Cliente, Número do Pedido, Data do Pedido).
Produto (Numero do Pedido, Código do Produto, Nome do Produto, Quantidade PEDIDA do Produto, Valor do Produto).
Detalhe a ser observado é que na questão, ele afirma que os totais não seriam persistidos. Isto tornaria o gabarito correto.
TRT 08ª Região – Analista Judiciário – 2010 – FCC
Considere um formulário eletrônico de pedidos onde conste o código e o nome do cliente que faz o pedido; o número e a data do pedido; e a lista de produtos pedidos contendo o código do produto, o nome do produto, a quantidade pedida do produto e o valor unitário do produto. Todos os dados serão persistidos em um SGBD relacional, com exceção dos totais. Todos os códigos são identificadores únicos.
Com a aplicação das formas normais (até a 3 FN) o resultado será a existência de, APENAS,
A) 2 tabelas.
B) 3 tabelas.
C) 4 tabelas.
D) 5 tabelas.
E) 6 tabelas.
RESPOSTA: C
Sem Normalização teríamos a tabela:
Pedido (Código do cliente, Nome do Cliente, Numero do Pedido, Data do Pedido, Produto (Código do Produto, Nome do Produto, Quantidade PEDIDA do Produto, Valor do Produto)).
1ª Forma Normal: Um esquema de relação R está na 1FN se todos os seus atributos forem atômicos (simples) e monovalorados, ou seja, não são permitidos atributos multivalorados, atributos compostos ou atributos multivalorados compostos. Ou seja, é necessário remover o atributo multivalorado “Produto” transformando-o em uma entidade.
Pedido (Código do cliente, Nome do Cliente, Número do Pedido, Data do Pedido).
Produto (Código do Pedido, Código do Produto, Nome do Produto, Quantidade PEDIDA do Produto, Valor do Produto).
2ª Forma Normal: Para estar na 2NF uma tabela deve estar na 1NF e todos os seus atributos que não façam parte de alguma chave candidata devem ser determinados unicamente por qualquer chave candidata da tabela. Se todas as chaves candidatas de uma tabela contiverem somente um atributo, esta já se encontra na 2NF. Ou seja, Se algum campo depender somente de parte de uma chave candidata composta (e não da chave composta como um todo), então este campo deve ser extraído para outra tabela.
Temos esse problema nas duas tabelas. Em Pedido temos o Nome Cliente que só depende da chave Código Cliente:
Pedido (Número do Pedido, Data do Pedido).
Cliente (Código do cliente, Nome do Cliente).
Já na tabela produto temos o Nome do Produto e Valor do Produto que dependem apenas da chave Código do Produto.
Pedido_x_Produto (Código do Pedido, Código do Produto, Quantidade PEDIDA do Produto).
Produto (Código do Produto, Nome do Produto, Valor do Produto)
3ª Forma Normal: A terceira forma normal (3NF) exige que a tabela esteja em 2NF e que todos os atributos que não são chave sejam mutuamente independentes, isto é, que não existam funções que definam um ao outro. Portanto, sempre a chave por inteiro deve definir toda a tabela. Isto exige que atributos que não dependem diretamente da chave sejam separados em uma tabela distinta. Em outras palavras, caso exista um ou mais atributos que dependam de um atributo não-chave, estes atributos deverão ser extraídos para outra tabela. No caso como pode ser observado não temos nenhum campo que dependa de um outro campo (não chave) para ser identificado. Então já está na terceira forma normal.
Sendo assim, temos um total de 4 tabelas.
TRT 08ª Região – Analista Judiciário – 2010 – FCC
São características de um banco de dados normalizado:
(A) Variedade acentuada de índices por tabela.
(B) Poucas tabelas largas com mais colunas.
(C) Poucos índices clusterizados.
(D) Várias tabelas estreitas com menos colunas.
(E) Muitas junções relacionais complexas.
RESPOSTA: D
Quando o banco de dados está normalizado existe a presença de diversas tabelas, e geralmente elas estão estreitas, pois a quantidade de colunas é distribuída entre a quantidade maior de tabelas. Já que as tabelas são mais coesas. Isso causa também a criação de muitas junções relacionais, mas não complexas.
TRT 08ª Região – Analista Judiciário – 2010 – FCC
Considere o esquema relacional da tabela abaixo: Venda (CodVenda, Cliente, Endereço, CEP, Cidade, Estado, Telefone, Produto, Quantidade, ValorUnitario, ValorTotal) A quantidade de tabelas, após a aplicação da primeira, segunda e terceira formas normais, será
A) 1
B) 2
C) 3
D) 4
E) 5
RESPOSTA: D
1ª Forma Normal: Separar dados multivalorados. Manter a atomicidade:
Venda (CodVenda, Cliente, Endereco, Cep, Cidade, Estado, Telefone, ValorTotal)
Produto (CodProduto, Quantidade, ValorUnitario)
2ª Forma Normal: Se um atributo depender apenas de uma parte da chave, então ela deve ir para outra tabela.
Venda (CodVenda, CodCliente, ValorTotal)
Cliente (CodCliente, Endereco, Cep, Cidade, Estado, Telefone)
Produto (CodProduto, Quantidade, ValorUnitario)
3ª Forma Normal: Se um atributo não depende da chave ele deve ser colocado em outra tabela.
Cliente (CodCliente, Endereco, Cep, Cidade, Estado, Telefone)
Venda (CodVenda, CodCliente, ValorTotal)
Venda_X_Produto (CodVenda, CodProduto, Quantidade)
Produto (CodProduto, ValorUnitario)
TRT 09ª Região – Analista Judiciário – 2010 – FCC
Em relação aos princípios fundamentais da análise de requisitos, considere:
Ajuda o analista a entender a informação, a função e o comportamento de um sistema, tornando a tarefa mais fácil e sistemática e tornando-se a base para o projeto, fornecendo ao projetista uma representação essencial do software, que pode ser mapeada num contexto de implementação.
A afirmação acima refere-se ao princípio
A) do reconhecimento do problema.
B) da avaliação e síntese.
C) da especificação.
D) da revisão.
E) da modelagem.
RESPOSTA: E
Modelagem é uma representação com um certo grau de abstração do sistema que serve para ajudar a compreensão do sistema. E que será utilizada para ajudar na implementação.
TRT 03ª Região – Analista Judiciário – 2010 – FCC
Considere uma tabela
I. com todas as suas colunas contendo somente valores atômicos (um único valor para cada linha).
II. cujos atributos não-chave são totalmente dependentes de toda a chave primária.
III. na qual alguns atributos não-chave são dependentes de outros atributos não-chave.
É correto afirmar que a tabela está normalizada até a
A) FNBC.
B) 1FN.
C) 2FN.
D) 3FN.
E) 4FN.
RESPOSTA: C
Primeiro Item é a 1FN, Segundo Item é a 2FN. O terceiro Item, deveria não estar acontecendo para estar na 3FN. Por esse motivo ele está apenas na 2FN.
TRT 20ª Região – Analista Judiciário – 2010 – FCC
Considere os seguintes componentes de modelos utilizados nos projetos de software:
I. Fluxo de dados.
II. Entidade fraca.
III. Entidade associativa.
IV. Depósito de dados.
V. Processo.
A correta associação entre estes componentes com a modelagem funcional (MF) e modelagem de dados (MD) é
A) I-MF; II-MD; III-MD; IV-MF; V-MF.
B) I-MD; II-MD; III-MD; IV-MF; V-MF.
C) I-MD; II-MD; III-MF; IV-MF; V-MF.
D) I-MD; II-MF; III-MD; IV-MF; V-MD.
E) I-MF; II-MF; III-MD; IV-MD; V-MF.
RESPOSTA: A
Modelagem Funcional (MF) tem como exemplo principal o DFD (Fluxo de Dados, Depósito de Dados, Processo, etc.), a Modelagem de Dados tem como exemplo o Modelo Entidade-Relacionamento (Entidade Fraca, Entidade Associativa, etc.).
TER-AM – Técnico Judiciário – 2009 – FCC
Se, e somente se, todas as colunas de uma tabela tiverem apenas valores atômicos, isto é, se cada coluna só puder ter um valor para cada linha na tabela.
Trata-se da definição da
a) 1FN.
b) 2FN.
c) 3FN.
d) FNBC.
e) 5FN.
RESPOSTA: A
1FN: Atributos atômicos e não-multivalorados. (nome, telefone, endereço)
Telefone (fixo, celular, etc) – multivalorado
Endereço (rua, bairro, CEP) – não atômico
2FN: Nenhum atributo NÃO-PRIMO deverá depender de todos os elementos de uma chave composta. Ex.: R(A*,B*,C,D) –> C ou D não podem depender somente de A ou B separados. Dica: se a chave for composta de apenas 1 atributo, já é 2FN automaticamente.
Atenção: se o atributo for primo (ex.: cpf) ele não precisa passar no teste de dependência total acima!
3FN: Não existe dependencia funcional transitiva de um atributo não chave até um atributo chave. Ex.: R(A*,B*,C,D) : D–>C–>A : Neste caso D depende de A transitivamente.
TER-AM – Técnico Judiciário – 2009 – FCC
A Forma Normal Boyce-Codd é considerada uma variação forte da
a) 1FN.
b) 2FN.
c) 3FN.
d) 4FN.
e) 5FN.
RESPOSTA: C
O conceito de normalização foi introduzido por E. F. Codd em 1972. Inicialmente Codd criou as três primeiras formas de normalização chamando-as de: primeira forma normal (1NF), segunda forma normal (2NF) e terceira forma normal (3NF). Uma definição mais forte da 3NF foi proposta depois por Boyce-Codd, e é conhecida como forma normal de Boyce-Codd (FNBC).
TCE-AL – Técnico Judiciário – 2008 – FCC
Uma relação estará na Segunda Forma Normal (2FN) se ela estiver na 1FN e todos os atributos
a) não chave forem dependentes não transitivos da chave primária.
b) não chave forem totalmente dependentes da chave primária.
c) chave forem dependentes não transitivos das chaves estrangeiras.
d) chave forem totalmente dependentes das chaves estrangeiras.
e) chave forem totalmente dependentes dos atributos não chave.
RESPOSTA: B
Os atributos não chaves não podem ser parcialmente dependentes. Ou seja, em uma chave composta, os atributos não-chave não podem depender apenas de uma parte da chave primária. Se isto ocorrer, significa que os atributos não chave junto com a parte da chave primária que eles dependem devem ser transferidos para uma nova tabela.
TRF 4ª Região – Técnico Judiciário – 2007 – FCC
Pretende-se derivar um relacionamento ternário totalmente n:m em tabelas lógicas relacionais normalizadas na 3FN. Esta operação deverá gerar corretamente
a) uma tabela.
b) duas tabelas.
c) três tabelas.
d) quatro tabelas.
e) cinco tabelas.
RESPOSTA: D