Metadados descrevem:
-
A as características dos dados com seu conteúdo, qualidade e condição.
-
B as características dos dados com seu conteúdo, qualidade e quantidade.
-
C as características dos dados com sua forma, qualidade e aplicação.
-
D as finalidades dos dados com sua forma, seu conteúdo, qualidade e condição.
-
E as finalidades da utilização dos dados, sua qualidade, condição e métodos de acesso.
Analise as afirmativas abaixo.
I. Atributo = dado que é associado a cada ocorrência de uma entidade ou de um relacionamento.
II. Relacionamento = conjunto de associações entre entidades.
III. Modelo de dados = conjunto de atributos e relacionamentos cujos valores distinguem uma ocorrência da entidade das demais.
IV. Cardinalidade de Relacionamentos = É o número (mínimo, máximo) de ocorrências de entidade associadas a uma ocorrência da entidade em questão através do relacionamento.
Estão corretas as afirmativas:
-
A I, III e IV somente.
-
B I, II e IV apenas.
-
C Apenas a I.
-
D Todas estão corretas.
Uma chave estrangeira é
-
A um conjunto de linhas de uma tabela, ordenado com a sequência em que os elementos são inseridos na base de dados.
-
B um conjunto de linhas de uma tabela, ordenado alfabeticamente de forma crescente ou decrescente.
-
C uma coluna, ou a combinação de colunas, cujos valores distinguem de forma unívoca uma linha das demais dentro de uma tabela.
-
D a combinação de uma ou mais colunas, adicionais à chave primária, que serve para distinguir uma linha em uma tabela.
-
E o mecanismo que permite a implementação de relacionamentos em um banco de dados relacional.
O entendimento dos modelos de banco de dados é fundamental para compreender as vantagens e desvantagens em aspectos de estrutura e manipulação dos dados. Um destes modelos utiliza tabelas bidimensionais para o armazenamento dos dados e a maneira como os dados são armazenados influencia na facilidade de acesso às informações, existindo técnicas de normalização para aperfeiçoar a organização. Trata-se do modelo
-
A hierárquico
-
B em rede.
-
C relacional.
-
D distribuído.
-
E orientado a objetos.
O uso de sistemas de banco de dados em aplicações web requer que o desenvolvimento seja feito em linguagem Java.
Certo
Errado
Por que eu devo ler este artigo: Este artigo objetiva apresentar conceitos estudados na �rea de banco de dados, servindo como base para que iniciantes na �rea possam entender com mais facilidade outros textos t�cnicos.
Um Banco de Dados representa uma cole��o de dados que possui algum significado e objetiva atender a um conjunto de usu�rios. Por exemplo, um cat�logo telef�nico pode ser considerado um BD. Sendo assim, um BD n�o necessariamente est� informatizado.
Quando resolvemos informatizar um Banco de Dados, utilizamos um programa especial para realizar essa tarefa. Tal programa � denominado SGBD � Sistema Gerenciador de Banco de Dados.
Podemos citar como exemplos de SGBDs: SQL Server, Oracle, Firebird, MySQL, Interbase, entre outros. Estes programas em geral s�o chamados SGBDs relacionais.
Em um SGBD relacional, enxergamos os dados armazenados em uma estrutura chamada tabela. Neste modelo, as tabelas de um Banco de Dados s�o relacionadas, permitindo assim que possamos recuperar informa��es envolvendo v�rias delas. Observe o exemplo abaixo:
Neste caso, a tabela Clientes est� relacionada com a tabela Telefones.Note que o cliente Marcio possui dois telefones: um residencial e um celular. A cliente Luciane possui um telefone celular, Wilkie possui um residencial e Marlos n�o possui telefone.
Entretanto, para que possamos implementar, de forma correta, um Banco de Dados utilizando algum SGBD, temos que passar por uma fase intermedi�ria � e n�o menos importante - chamada modelagem de dados.
Quando estamos aprendendo a programar, em geral dividimos esta tarefa em tr�s fases:
- Entendimento do problema;
- Constru��o do algoritmo;
- Implementa��o (linguagem de programa��o).
Em se tratando de banco de dados n�o � muito diferente:
- Entendimento do problema;
- Constru��o do modelo ER � entidade e relacionamento;
- Implementa��o (SGBD).
Entender determinado problema nem sempre � uma tarefa f�cil, principalmente se voc� n�o est� familiarizado com a �rea de atua��o de seu cliente. O profissional de inform�tica precisa dominar a tecnologia, e al�m disso precisa ter habilidade para saber ouvir o cliente e ao mesmo tempo abstrair o que realmente � necess�rio para a implementa��o de alguma solu��o utilizado a tecnologia (in)dispon�vel.
Antes da implementa��o em um SGBD, precisamos de uma descri��o formal da estrutura de um banco de dados, de forma independente do SGBD. Essa descri��o formal � chamada modelo conceitual.
Costumamos representar um modelo conceitual atrav�s da abordagem entidade�relacionamento (ER). Nesta abordagem construimos um diagrama, chamado diagrama entidade-relacionamento. Observe abaixo o diagrama que originou as tabelas Clientes e Telefones:
Entidade pode ser entendida como uma �coisa� ou algo da realidade modelada onde deseja-se manter informa��es no banco de dados (BD). Por exemplo, em um sistema escolar, algumas entidades podem ser os alunos, professores, hor�rio, disciplinas e avalia��es. Note que uma entidade pode representar tanto objetos concretos (alunos), quanto objetos abstratos (hor�rio). A entidade � representada por um ret�ngulo, que cont�m o nome da entidade. Observe o exemplo abaixo.
A entidade ALUNO representa todos os estudantes sobre as quais se deseja manter informa��es no BD. Quando � necess�rio especificar um objeto particular (para o exemplo, determinado estudante) usa-se o termo ocorr�ncia de entidade.
Relacionamento � um conjunto de associa��es entre entidades. O relacionamento � representado por um losango. Esse losango � ligado por linhas aos ret�ngulos que representam as entidades participantes do relacionamento. O exemplo abaixo possui duas entidades, M�DICO e PACIENTE, e um relacionamento chamado CONSULTA.
O modelo acima informa que o BD mant�m informa��es sobre m�dicos, pacientes, al�m de um conjunto de associa��es (consulta), cada uma ligando um m�dico a um paciente. Quando � necess�rio especificar um relacionamento particular (para o exemplo, determinada consulta) usa-se o termo ocorr�ncia do relacionamento. Uma ocorr�ncia de consulta envolve a ocorr�ncia de determinado m�dico e a ocorr�ncia de determinado paciente.
Um relacionamento pode envolver ocorr�ncias de uma mesma entidade. Neste caso, estamos diante de um auto-relacionamento. Observe o exemplo:
CASAMENTO � um relacionamento que envolve duas ocorr�ncias da entidade PESSOA. Para facilitar o entendimento, em geral costumamos identificar o papel de cada entidade no relacionamento (para o exemplo, marido e esposa).
Cardinalidade do relacionamento
Observe o modelo abaixo:
Estamos diante de um relacionamento (possui) entre as entidades EMPREGADO e DEPENDENTE. Considere as seguintes quest�es:
- Um empregado pode n�o ter dependentes?
- Um dependente pode ter mais de um empregado associado?
- Determinado empregado pode possuir mais de um dependente?
- Pode existir dependente sem algum empregado associado?
Na realidade, as respostas desses questionamentos dependem do problema sendo modelado. Entretanto, para que possamos expressar essas id�ias no modelo, � necess�rio definir uma propriedade importante do relacionamento - sua cardinalidade.
A cardinalidade � um n�mero que expressa o comportamento (n�mero de ocorr�ncias) de determinada entidade associada a uma ocorr�ncia da entidade em quest�o atrav�s do relacionamento.
Existem dois tipos de cardinalidade: m�nima e m�xima. A cardinalidade m�xima, expressa o n�mero m�ximo de ocorr�ncias de determinada entidade, associada a uma ocorr�ncia da entidade em quest�o, atrav�s do relacionamento. A cardinalidade m�nima, expressa o n�mero m�nimo de ocorr�ncias de determinada entidade associada a uma ocorr�ncia da entidade em quest�o atrav�s do relacionamento. Usaremos a seguinte conven��o para expressar a cardinalidade:
Observe as cardinalidades m�nima e m�xima representadas no modelo abaixo:
Para fazermos a leitura do modelo, partimos de determinada entidade e a cardinalidade correspondente a essa entidade � representada no lado oposto. Em nosso exemplo, a cardinalidade (0:N) faz refer�ncia a EMPREGADO, j� a cardinalidade (1:1), faz refer�ncia a DEPENDENTE. Isso significa que:
- Uma ocorr�ncia de empregado pode n�o estar associada a uma ocorr�ncia de dependente ou pode estar associada a v�rias ocorr�ncias dele (determinado empregado pode n�o possuir dependentes ou pode possuir v�rios);
- Uma ocorr�ncia de dependente est� associada a apenas uma ocorr�ncia de empregado (determinado dependente possui apenas um empregado respons�vel).
Na pr�tica, para as cardinalidades m�ximas, costumamos distinguir dois tipos: 1 (um) e N (cardinalidades maiores que 1). J� para a as cardinalidades m�nimas, costumamos distinguir dois tipos: 0 (zero) e 1 (um).
Atributo � uma caracter�stica relevante associada a cada ocorr�ncia de entidade ou Relacionamento. Observe no modelo abaixo a nota��o utilizada para atributos:
Cardinalidade do atributo
Observe que o modelo acima n�o informa se determinado aluno pode ter v�rios telefones, ou mesmo se algum aluno pode n�o ter telefones. Para deixar o modelo mais preciso, costumamos expressar cardinalidade para os atributos. Observe a cardinalidade do atributo telefone no modelo abaixo:
Dessa forma, podemos concluir que determinado aluno pode n�o ter telefone (cardinalidade m�nima zero) ou pode ter v�rios (cardinalidade m�xima N). A cardinalidade dos atributos c�digo e nome � (1,1). Por conven��o, ela foi omitida do diagrama.
No caso de atributos, a cardinalidade m�nima 1 indica que o atributo � obrigat�rio e a cardinalidade m�xima 1 indica que o atributo � monovalorado. Para o atributo telefone, a cardinalidade m�nima 0 indica que o mesmo � opcional e a cardinalidade m�xima N informa que ele � multivalorado.
Saiba mais sobre Banco de Dados e Modelagem de Dados ;)
- Guia de Modelagem de Dados:
Essa guia ter� como objetivo apresentar a modelagem de dados, desde seus primeiros passos com banco pequenos at� a modelagem para bancos Big Data. - Banco de Dados para Programadores:
Todo programador deveria entender de banco de dados para ser um profissional mais completo, mas isso n�o � tarefa simples. Nesse guia voc� ir� aprofundar seus conhecimentos em SQL, modelagem, e os principais SGBDs do mercado. Vamos evoluir!
Confira outros conte�dos:
Por Reinaldo Em 2006