Julia é uma WebDesigner e recebeu um modelo de dados com a seguinte especificação de um campo a ser armazenado no banco de dados DB_ProcessJud do sistema SIS_ProcessJud. NUM_PROCESSO, INTEGER, NOT NULL, PRIMARY KEY A partir do modelo de dados recebido, Julia pode concluir que NUM_PROCESSO é um campo:
- A)inteiro de acesso reservado;
Errada, porque PRIMARY KEY não significa 'acesso reservado'; trata-se de uma chave de identificação da tabela, e não de permissão de acesso.
- B)do tipo caractere com tamanho fixo;
Errada, porque o campo foi definido como INTEGER, não como caractere de tamanho fixo.
- C)utilizado como chave de acesso ao sistema SIS_ProcessJud;
Errada, porque uma chave primária identifica registros no banco, não funciona como chave de login ou acesso ao sistema.
- D)que permite o armazenamento de valores nulos em determinadas circunstâncias;
Errada, porque NOT NULL indica justamente o contrário: o campo não aceita valores nulos.
- E)identificador único de um registro em uma tabela do banco de dados DB_ProcessJud.
Certa, porque PRIMARY KEY identifica de forma única cada registro da tabela e não admite duplicidade nem nulidade.
Gabarito: E
A questão mistura leitura de modelo de dados com noções básicas de banco relacional. Quando você vê um campo descrito como INTEGER, NOT NULL e PRIMARY KEY, já dá para tirar três conclusões importantes: ele armazena um número inteiro, não aceita valor nulo e faz parte da identificação formal do registro. Em outras palavras, não é um campo qualquer na tabela, é o campo que distingue cada linha das demais. O ponto central aqui é o comando PRIMARY KEY. Em banco relacional, a chave primária identifica unicamente cada registro da tabela e, por regra, não pode repetir nem ser nula. É exatamente por isso que o gabarito está na alternativa que fala em identificador único de um registro. Essa é a ideia clássica ensinada em teoria de banco de dados e compatível com o modelo relacional de Codd: cada tabela precisa de um mecanismo para identificar de forma inequívoca suas linhas. Repare também que o nome do campo, NUM_PROCESSO, ajuda no contexto, mas não muda a lógica técnica. O que manda aqui é a especificação do atributo no modelo. Se a banca diz PRIMARY KEY, você pensa imediatamente em chave primária, não em acesso ao sistema, nem em tipo caractere, nem em nulidade. O campo pode até ser um número de processo do mundo real, mas, no banco, ele está desempenhando o papel de identificador da tabela. Então, resumindo com carinho de prova: INTEGER indica o tipo, NOT NULL elimina a possibilidade de valor vazio, e PRIMARY KEY fecha a porta para duplicidade. Por isso, a alternativa correta é a que diz que esse campo é um identificador único de um registro na tabela do banco de dados.