-
Errado.
Porque vai depender da regra de negócio implementada. Supõe que não serão cadastrados nem CPF e nem CNPJ e apenas a matrícula?
-
Gabarito Errado
Muito boa resposta do companheiro Rodrigo Marcelo ! Parabéns !
"Retroceder Nunca Render-se Jamais !"
Força e Fé !
Fortuna Audaces Sequitur !
-
Complementando a repsosta do Rodrigo...
Ou pode muito bem, como na maioria dos casos que presenciei, criar um ID pra ser PK e FK.
exemplo: Tabela Pessoa -> id_pessoa(pk), nome, cpf, sexo....
-
ERRADO
Eu acho que houve uma estrapolação na interpretação. Como é típico do CESPE, eles fizeram uma afirmação: "Na criação de uma tabela para os clientes de uma organização..".
Será criada UMA tabela Cliente e eles querem que CPF seja chave para PF e CNPJ seja chave para PJ.
Nesse caso estamos diante da GENERALIZAÇÃO e quando há generalização NUNCA É INDICADO que atributos específicos sejam chaves, pois eles estariam presentes somente em um dos elementos. O correto nessa situação é a criação de um campo ID ou a ESPECIALIZAÇÃO da Tabela CLIENTE.
-
Errei a questão mas entendi bem o erro:
Dando uma pesquisada sobre o assunto, vi que o motivo de não se recomendar o uso do CPF/CNPJ como chave primária envolve o conceito de chave primária natural (no caso algo diretamente ligado ao usuário) e chave primária artificial (gerada pelo BD), a recomendação é não se utilizar chave primária natural porque esta não está sobre o controle do programador ou gerenciador do banco de dados, a qualquer momento o governo pode eliminar o cpf aí imagina só a dor de cabeça; outro motivo seria também que nem todo mundo tem cpf (crianças, estrangeiros etc.).
https://imasters.com.br/banco-de-dados/chaves-artificiais-ou-naturais-no-banco-de-dados/?trace=1519021197&source=single
-
FONTE: https://www.devmedia.com.br/sql-aprenda-a-utilizar-a-chave-primaria-e-a-chave-estrangeira/37636
A chave primária é utilizada como o identificador único da tabela, sendo, então, representada, por aquele campo (ou campos) que não receberá valores repetidos.
Por causa disso, existe uma lista de características que deve ser levada em consideração ao definir uma chave primária:
Chaves primárias não podem ser nulas;
Cada registro na tabela deve possuir uma, e somente uma, chave primária;
Normalmente, chaves primárias são incrementadas automaticamente pelo banco de dados, ou seja, não há necessidade de passarmos esse valor em um INSERT. Entretanto, essa é uma opção configurada na criação da base de dados que não é obrigatória. Nos casos em que ela (incremento automático) não é definida, é preciso garantir que não haverá valores repetidos nessa coluna;
São as chaves para o relacionamento entre entidades, ou tabelas, da base de dados. Assim, haverá, na tabela relacionada, uma referência a essa chave primária (que será, na tabela relacionada, a chave estrangeira).
-
Teoricamente pode, mas não é a mais indicada
-
Tem uma série de motivos para não usar o CPF, CNPJ, entre eles, por exemplo, nem todo mundo tem CPF, assim seria restringido o cadastro. Usando uma chave artificial gerada pelo banco de dados evitaria esse problema.
-
GABARITO: ERRADO
Em um banco de dados podem haver chaves concorrentes (chaves primárias candidatas, tais como código de cliente, CPF, título eleitoral, etc..). Cabe ao administrador do BD definir a Primary Key mais indicada, ou seja, não há em lugar algum pré-definido que DEVE ser sempre CPF ou CNPJ as PKs.
Fonte: IFRO- You Tube (curso EAD sobre Banco de Dados- aula 2)
https://www.youtube.com/watch?v=GRlaxk7bt1c&list=PLGQaz0PPd2PEcog2VETN0k41IcbPeiS3z&index=12
Bons Estudos!
-
ERRADO!
chaves não podem ser multivaloradas
-
gabriela X, e oq isso tem a ver com a questao?
-
Gabriela:
1º CPF + CNPJ (Concatenação) poderia sim ser uma chave primária, a chamada chave composta. O erro não é esse. Ao meu ver, o problema seria em uma pessoa que não tivesse CPF...
-
Geralmente o cenário de atuação de clientes, envolvem outros relacionamentos,
como produtos, contratos, prazos, o que pode gerar inconsistência no BD caso
se utilize os fields CPF e CNPJ como KP.
-
Discordo. Sou Analista de Sistemas e entendo que CPF e CNPJ são valores únicos e invariáveis de uma empresa ou de uma pessoa. Geralmente valores com essas características são SIM os mais indicados para serem usados como chave primária de uma entidade de banco de dados.
Podem ser utilizados outros atributos que também costumam ser únicos, como RG, Código e etc. Mas os famosos "códigos de cadastro" ou "códigos de cliente", muito comuns durante os anos 90 e início dos anos 2000, já caíram em desuso e atualmente os atributos chave mais utilizados para inserção de Pessoas (físicas ou jurídicas), em um banco de dados relacional, são exatamente CPF e CNPJ...
Típica questão em que saber demais te atrapalha invés de ajudar...
-
Para resolver essa questão, devemos ter em mente os conceitos de chave natural e chave art ificial. Uma ch ave natural é formada por um ou mais atributos que fazem parte do negócio modelado (CPF, RG, etc). Por outro lado, a chave artificial é composta por um atributo que não representa nenhuma propriedade do negócio, geralmente é um n úmero sequencial criado unicamente para manter a unicidade e ident ificar a instância de uma entidade (ID).
A escolha de uma chave natural pode representar alguns problemas e, portanto, nem sempre é a mais indicada para funcionar com chave primária de uma entidade. Vamos supor que usemos o CPF como chave primária para nossos clientes. Como serão cadastrados os clientes estrangeiros que não possuem CPF ou os menores de idade que não possuem CPF? Seu modelo ficará limitado. Para evitar esse problema, é possível cr iar uma chave artificial e sequencial: id_cliente, por exemplo.
Gabarito: Errado.
Fonte: https://www.passeidireto.com/arquivo/68978249/bd-relacional-exponencial-visto-118-pg
-
ERRADO
Algumas dicas de CHAVE PRIMÁRIA:
Identifica exclusivamente alguém.
Pode ser composta por mais de um registo(Ex: Agência e Conta - ambas são uma só chave primária).
Não pode conter valores nulos.
Zero "0" não é valor nulo.
Item não chave primária poderá conter valores nulos.
O CPF "PODE" ser uma chave primária. Porém não é uma escolha mais indicada.
-
Galera, muito cuidado com as pegadinhas do Cespe.
O comando da questão diz: “Na criação de UMA tabela PARA OS CLIENTES de uma organização.....[ ], OS ATRIBUTOS de CPF e CNPJ, RESPECTIVAMENTE, são...[ ] para se representar a chave primária DA TABELA”.
Primeiro: O comando diz: a criação de UMA tabela (sabemos que ambas as chaves são candidatas à chave primária). No entanto, sendo uma TABELA PARA OS CLIENTES da organização, é possível o cliente ser Pessoa física ou Jurídica. Portanto, OU será CPF (pessoa física) OU será o CNPJ (Pessoa Jurídica), concordam?
Segundo: A palavra “RESPECTIVAMENTE” quer dizer, “NESSA ORDEM” (consultem os sinônimos). Deve se perguntar: É possível determinar a ordem nessa criação, ou depende do tipo de cliente?
Temos então as seguintes conclusões:
Percebam que, o mérito do comando da questão não trata se CPF e CNPJ podem ou não ser chave primária. A questão trata das peculiaridades da criação de uma chave e, situações em que não são permitidos determinados valores ou ações.
*No mundo acadêmico, na criação de uma tabela para clientes de uma organização, os atributos CPF/CNPJ é uma escolha indicada para representar chave primária dessa tabela. (Fonte: Luciano Freitas - Perito Criminal) Projetos Missão.
CUIDADO! O Cespe gosta muito disso. “Te dá duas ou mais opções corretas para resolução do problema, mas com ações que não fazem o menor sentido.
*Vejo vocês na academia! Grande abraço!
-
E.
Não podemos afirmar que esses atributos são a “escolha mais indicada” para representar a chave primária (primary key - PK). Apesar serem campos que não se repetem (não há duas pessoas com o mesmo CPF), pode haver casos que fazem com que esses campos não sejam a perfeita escolha.
Um dos exemplos é uma pessoa que ainda não tenha um CPF ou um cliente estrangeiro, que não é cadastrado nesse documento. Outro exemplo envolve os conceitos de minimalidade, chave artificial e natural: A chave primária segue o conceito de minimalidade, portanto, é comum que o CPF e o CNPJ (chave natural, pois atributo ligado ao objeto, ou seja, à pessoa) sejam definidos como a chave primária, evitando a geração de um novo campo (chave artificial - campo designado no banco de dados) para funcionar como chave primária. Por outro lado, seguindo o mesmo conceito (minimalidade), observe que um CNPJ possui 14 dígitos. Caso usasse uma chave artificial incremental, essa quantidade de dígitos seria suficiente para o cadastro de mais de 9 trilhões de clientes! Ou seja, se esse banco tiver, por exemplo, 99 mil clientes (5 caracteres, caso todos numéricos e incrementais ou até menos, se uma mistura de letras e números), estaria usando muito menos recurso computacional ao optar por uma chave artificial como primária (como um código de cliente) em vez da chave natural (CPF e CNPJ).
-
O mais indicado é que a chave seja algo controlável pela empresa.
Um número de Registro por exemplo.
-
Gabarito: Errado.
Assim como em questões do Direito, depende da realidade aplicada à construção do banco de dados. Embora sejam utilizados por serem documentos personalíssimos, como a maioria dos documentos que são expedidos, não significa que, a qualquer caso, eles serão aplicados. A questão foi rasa nisso, por isso marquei errado. Por exemplo, existem pessoas que não tem CPF e CNPJ. Da mesma forma que com outro possível documento identificador ou outro atributo. Depende da necessidade de construção do banco de dados.
Qualquer equívoco, avisem-me.
Bons estudos!
-
Pessoal, a chave primária deve ser um identificador único em todo o conjunto de entidades.
Assim, é utilizado para encontrar somente 1 registro na tabela.
Se você matricular seus 3 filhos em uma escola e a escola colocar seu CPF como atributo chave, quando alguém da administração for consultar esse atributo, encontrará 3 registros.
É por isso que na escola/faculdade você possui uma matrícula individual como atributo chave, para que a administração encontre somente 1 registro quando essa matrícula for pesquisada.
Como outros exemplos temos: Código, Renavam, Chassi.
Lembrando que em alguns casos você até pode utilizar o CPF como atributo chave, mas são raros os casos e o CEBRASPE já passificou que não se deve utilizar.
Fonte: Curso do Prof. Ricardo Beck.
-
Quanto comentário bizarro, cada um dá uma enrolada e no final não explica nada. A chave primária só precisa ser 2 coisas: não nula e única. Como cada CPF e CNPJ é único, eu acredito que o problema seja a empresa contratar com alguém que não tenha CPF ou CNPJ, se é que isso é possível
-
Errado.
Teoricamente não há nenhum problema em usar CPF ou CNPJ.
Note que eles conseguem, teoricamente, identificar de maneira única uma linha na tabela.
Contudo, o uso dele pode levar a alguns problemas práticos.
Por exemplo, uma pessoa pode não ter CPF.
Nesse caso, seria impossível inseri-la no banco de dados. Assim, seria melhor usar um código sequencial.
-
Gaba: ERRADO
Comentários: o mais aconselhável é criar uma chave primária, tipo: "codigo_cliente".
imagine que vc vai criar um sistema para controlar o tempo de acesso a uma área de brinquedos para criança, vc já deve ter visto isso em algum shopping, logo, o cadastro deve ter poucos campos ( codigo_cliente, nome, idade, responsavel, telefone, hora_entrada, hora_saida, valor_hora), note que criança não tem CPF nem CNPJ.
-
Quando eu penso que aprendi...
-
PAREM DE BUSCAR PELO EM OVO
A questão apresenta a seguinte situação:
Criar uma única tabela, para pessoas físicas e jurídicas.
Logo, não é possível ter CPF e CNPJ como chaves primárias separadas, pois
a chave primária é única.
O correto seria atribuir um Código do Cliente como chave primária.
-
O mais indicado é a criação de um código do cliente.
Pois todos os setores podem ter acesso ao código do cliente, no entanto nem todos os setores as vezes tem acesso ao CPF e CNPJ por exemplo.
-
Parafraseando nosso colega Adeilson Aragão "Errei a questão mas entendi bem o erro:"
Preciso estudar mais.
-
cada as respostas dos professores pra banco de dados? quase nenhuma questão do assunto tem comentário feito pelo professor
-
Errei porque achei que CPF e CNPJ eram únicos, mas pelo jeito não kkkkkkkkkkkkk
Deve existir duplicados por aí!
-
eu entendi que o cpf e o cnpj seriam chaves primarias e com isso invalidariam a questao, pois nao pode ter duas chaves primarias
-
A PK deve ser um ID!
Alguns motivos:
- Novo requerimento e você precisa cadastrar um cidadão estrangeiro. Vai colocar passaporte? Mas o passaporte muda constantemente?!
- Só recentemente o CPF começou a abranger de forma mais intensa os menores de idade. E se isso muda? Vai cadastrar como?
- Sai uma lei no Brasil criando um documento único, tornando CPF obsoleto, ou adicionando um dígito ao CPF. O que você faz? Seria uma coisa simples alterar os dados mestre da pessoa no seu sistema, mas se você cometeu o enorme engano de modelar o CPF como chave primária você precisar parar o sistema produtivo e rodar rotinas de conversão que podem demorar horas ou dias.
-
Na criação de uma tabela para os clientes de uma organização, os atributos de CPF e CNPJ, para pessoas físicas e jurídicas, respectivamente, são a escolha mais indicada para representar a chave primária (PK) da tabela.
Uma tabela = Uma chave primária.
Registros de PF e PJ na mesma tabela teriam CPF e CNPJ.
CNPJ 00.000.000.0001-55 (14 dígitos)
CPF 123.456.789-11 (11 dígitos)
Campos de tamanhos distintos e não obrigatórios (já que PF não tem CNPJ e PJ não tem CPF).
Não teríamos identificação única.
-
GABARITO: ERRADO
É possível ter uma pessoa física que não possui CPF. Um exemplo é um estrangeiro, não residente no país. Se, para realizar a venda, fosse necessário registrar o cliente estrangeiro, você teria problemas, pois ele não possui o CPF no formado brasileiro. Assim, não daria para registrar, pois a chave primária não pode ter valor nulo.
Portanto, chaves primárias "naturais" devem ser evitadas. O ideal seria usar a chave substituta, a qual é gerada automaticamente pelo sistema.
-
Outro detalhe nao apontado:
As Chaves Primárias (PK) nao pode ter valor nulo (NULL).
Assim, no caso de uma única tabela, ao ter relacionados clientes com naturezas jurídicas diferentes, teríamos o valor nulo para o atributos incompatíveis com a sua natureza. Por ex: Pessoa Física tem CPF. Logo, se a PK selcionada for CNPJ esse valor ficaria nulo - o que nao é possível. Outros clientes podem nao possuir nenhum dos 2 atributos...
Nesse caso, recomenda-se criar uma chave artificial como código do cliente.