Podemos dizer que o termo “banco de dados” já pertence ao linguajar popular, pois, de modo geral, tal termo é compreendido como o ato se armazenar dados. O conceito de banco de dados aparece no cotidiano e também em muitas notícias.

• “Empresa comercializa banco de dados de DNA usado para resolver crimes” (OLHAR DIGITAL, 2019).
• “Comissão aprova criação de banco de dados sobre drogas experimentais para câncer” (BRASIL, 2019).
• “Rio Grande do SUL é o estado que mais localizou desaparecidos com o uso do banco de dados com perfil genético” (G1, 2020).
• “Saiba como funciona o Cadastro Positivo. E veja como tirar seu nome do banco de dados” (O GLOBO, 2020).

Ainda que o conceito de banco de dados seja dito de conhecimento geral, é muito importante saber seu significado na área da computação. Tentando compreender melhor o significado desse termo para a computação, vejamos algumas das principais definições da bibliografia.

Para Casanova, Tucherman e Laender (1990, p. 2), “um banco de dados é um conjunto de dados armazenados, cujo conteúdo informativo representa, a cada instante, o estado atual de uma determinada aplicação”.

Date (2004) define banco de dados como uma coleção de dados operacionais armazenados, sendo usados pelos sistemas de aplicação de uma determinada organização. Para Chu (1983), um banco de dados é um conjunto de arquivos relacionados entre si. Um banco de dados é uma coleção de dados relacionais (ELMASRI; NAVATHE, 2005).

Sendo assim, podemos notar que em todas as definições há um termo em comum: relacionamento. Isso significa que um banco de dados não tem apenas a missão de armazenar dados, mas também que esses dados estejam interligados entre si. Por isso, vamos assumir que um banco de dados é um conjunto de dados relacionados entre si.

Arquitetura de Banco de Dados

O termo arquitetura pode ser um tanto quanto abrangente, mas quando falamos de arquitetura de banco de dados, estamos falando de como um banco de dados se comporta, em relação aos usuários e aplicação.

Um componente essencial para compreender a arquitetura de um banco de dados é o sistema gerenciador de banco de dados.

Um sistema gerenciador de banco de dados (SGBD) é uma coleção de programas que permite aos usuários criar e manter um banco de dados. O SGBD é, portanto, um sistema de software de propósito geral que facilita os processos de definição, construção, manipulação e compartilhamento de bancos de dados entre vários usuários e aplicações. A definição de um banco de dados implica especificar os tipos de dados, as estruturas e as restrições para os dados a serem armazenados em um banco de dados. (ELMASRI, NAVATHE, 2005, p. 10).

De modo geral, podemos compreender o SGBD como um programa de computador responsável pelo gerenciamento dos dados. A Figura 2.1 apresenta a arquitetura de funcionamento do banco de dados e o SGBD.

#PraCegoVer: O esquema apresentado reflete a ligação entre 3 aplicações e o sistema gerenciador de banco de dados que possui a sigla SGDB. O SGDB é caracterizado por um conjunto de ferramentas que gerenciam os bancos de dados, o esquema então configura a ligação entre as três aplicações e o SGDB e em seguida a ligação entre o SGDB e o banco de dados.

O papel do SGBD é fazer a interface entre usuários e aplicações com os dados em si, o que significa que as aplicações nunca acessam os dados diretamente, se comunicam com o SGBD e este se torna responsável por controlar o acesso aos dados.

Logo, o SGBD tem diversas tarefas importantes no que se refere ao uso e manipulação de um banco de dados. Segundo Elmasri e Navathe (2005), são eles:

• Definição : A definição de um banco de dados trata da construção da estrutura do mesmo. Nesse momento serão definidos os tipos de dados e as restrições para os dados que serão armazenados;
• Construção : A construção de um banco de dados é o processo de armazenar os dados em um tipo de disco ou mídia definido pelo sistema gerenciador de banco de dados;
• Manipulação : A manipulação é o processo de inserir, atualizar, remover e realizar consultas sobre os dados;
• Compartilhamento : O compartilhamento permite com que vários usuários e sistemas acessem ao mesmo tempo os dados armazenados em um banco de dados;
• Proteção : A proteção está relacionada ao encapsulamento dos dados, bem como ao tratamento de quebras no sistema.

Uma vez compreendido como funciona a arquitetura de um banco de dados, a partir de agora, estudaremos os modelos de banco de dados, bem como compreenderemos o ciclo de vida de um banco de dados.

Assim como no desenvolvimento de um sistema, o projeto de um banco de dados envolve uma série de etapas que visam garantir a integridade dos dados armazenados.

O desenvolvimento de um banco de dados tem seu próprio ciclo de vida, que pode ser inserido ao ciclo de vida de um sistema. O ciclo de vida de um banco de dados é composto, basicamente, pelos seus níveis, compostos pelos modelos: modelo conceitual, modelo lógico e modelo físico.

Um modelo de (banco de) dados é uma descrição dos tipos de informações que estão armazenadas em um banco de dados. Por exemplo, no caso da indústria citado acima, o modelo de dados poderia informar que o banco de dados armazena informações sobre produtos e que, para cada produto, são armazenados seu código, preço e descrição. Observe que o modelo de dados não informa quais os produtos que estão armazenados no banco de dados, mas apenas que o banco de dados contém informações sobre produtos (HEUSER, 2009, p. 16).

A partir do próximo tópico, compreenderemos cada um dos modelos de banco de dados em um maior nível de detalhamento.

Modelo Conceitual

O modelo conceitual é tido como o modelo de mais alto nível, ou seja, é um modelo de fácil compreensão, mesmo aos usuários com baixo conhecimento em tecnologia.

O objetivo desse modelo é justamente com que tais usuários o compreendam. A construção do modelo lógico pode ser feita utilizando o documento de requisitos e o diagrama de casos de uso. O mesmo pode ser validado com tais documentos, mas complementarmente pode ser validado junto ao cliente utilizando como recurso o modelo conceitual.

A técnica de modelagem de dados mais difundida e utilizada é a abordagem entidade-relacionamento (ER). Nessa técnica, o modelo de dados é representado através de um modelo entidade-relacionamento (modelo ER). Usualmente, um modelo ER é representado graficamente, através de um diagrama entidade relacionamento (DER). A abordagem ER foi criada em 1976 por Peter Chen. Ela pode ser considerada como um padrão de fato para modelagem conceitual. Mesmo as técnicas de modelagem orientada a objetos que têm surgido nos últimos anos baseiam-se nos conceitos da abordagem ER (HEUSER, 2009, p. 22).

Assim como sugere o nome, diagrama entidade relacionamento é composto por dois elementos principais: entidades e relacionamentos. Graficamente, uma entidade é representada por um retângulo, e um relacionamento é representado por um losango.

#PraCegoVer: O diagrama de entidade e relacionamento permite ao usuário compreender a relação entre as entidades, deixando claro qual a forma que elas se relacionam, neste caso temos duas entidades representadas por retângulos e que se relacionam através da representação de um losango, as ligações entre os dois retângulos e o losango é realizada através de linhas contínuas.

Uma entidade representa um objeto do mundo real sob o qual se deseja armazenar dados. Nesse caso, mundo real é o sistema, seus requisitos e componentes, já no exemplo do sistema acadêmico, mundo real é o sistema da universidade em si.

Um relacionamento faz o mapeamento de como as entidades interagem entre si. Por exemplo, no sistema acadêmico um aluno assiste a uma aula, portanto, o ato de assistir é o relacionamento (Assiste) que liga o aluno com aula.

#PraCegoVer: Este é um típico exemplo de entidade e relacionamento, é composto por duas entidades denominadas de aluno e aula, em que possuem um relacionamento, o relacionamento foi denominado de assiste, ou seja, a entidade aluno assiste a aula. Os nomes ficam dentro dos elementos, as entidades aluno e aula são representadas por dois retângulos com seus respectivos nomes dentro, e o relacionamento é representado por um losango com o nome assiste dentro, por fim a ligação entre os três elementos ocorre através de linhas contínuas.

Elementos do Diagrama Entidade Relacionamento

Um diagrama entidade relacionamento não é composto apenas de seus dois elementos principais, mas também de outros que auxiliam a compor a estrutura de um banco de dados.

O primeiro elemento desse diagrama é o atributo. O atributo pertence à entidade e deverá descrever quais são as características de uma entidade no mundo real. No contexto do sistema acadêmico, vamos pegar como exemplo a entidade aluno.

Para obter isso, devemos analisar os documentos de requisitos, juntamente com o diagrama de casos de uso e fazer a seguinte pergunta: Quais são os atributos do meu aluno dentro do sistema? Para abstrair melhor já imagine a tela de cadastro do aluno no sistema.

Sendo assim, vejamos a seguir um exemplo de como ficaria a entidade aluno, juntamente com alguns atributos. Na notação gráfica da figura 2.4, os atributos são denotados por um círculo pequeno, seguido do nome do atributo. Se o círculo estiver pintado, significa que será um atributo identificador. Um atributo identificador é aquele capaz de identificar unicamente cada registro em um banco de dados.

#PraCegoVer: As entidades são caracterizadas por seus atributos, por sua vez os atributos em um diagrama de entidade e relacionamentos são elementos representados por um pequeno círculo seguido de descrição que fica conectado ao retângulo da entidade através de linhas contínuas, neste caso a entidade aluno possui quatro atributos que são denominados respectivamente de ID_Aluno, Nome, CPF e Endereço.

Tratando-se dos tipos de atributos de uma entidade, podemos representar conforme a Figura 2.5.

#PraCegoVer: Os tipos de atributos são representados basicamente seguindo as suas características, no diagrama apresentado encontramos a entidade pessoa composta dos atributos ID_Aluno, Nome, CPF, Observação, RG, Endereço e Telefone. O atributo ID_Aluno é do tipo identificador, o atributo nome é do tipo simples, o atributo CPF é obrigatório por isso ao lado do seu nome temos a representação entre parentes de 1, 1, esta notação representa que é preciso ter um e apenas um cpf obrigatoriamente, o atributo observação não é obrigatório, porém só deverá receber uma observação, então após a descrição do atributo encontramos entre parênteses com o valor 0, 1, da mesma forma acontece com o atributo RG. O atributo Endereço é especial, pois é um atributo composto, isto significa que é uma representação de dois outros atributos, no caso, rua e bairro. Finalmente o último atributo denominado telefone, este atributo pode possuir nenhum ou vários telefones, então sua representação é realizada também com os parênteses ao final da descrição, porém neste caso entre os parênteses encontramos 0, N para representa nenhum ou muitos telefones.

O relacionamento entre as entidades é mapeado por intermédio das cardinalidades. A cardinalidade indica como que uma entidade participa de um relacionamento.

#PraCegoVer: O diagrama procura exemplificar a cardinalidade entre o relacionamento das entidades, uma entidade se relaciona com outra e o relacionamento recebe valores colocados entre parênteses e separados por vírgula que podem ser zero para não existir, um para ter um elemento ou n para vários elementos. O primeiro valor representa o valor mínimo e o segundo valor representa o valor máximo.

Para compreender melhor a cardinalidade, considere o diagrama entidade relacionamento, na Figura 2.7 a seguir:

#PraCegoVer: O exemplo de cardinalidade mostra três relações entre seis entidades, a primeira relação é entre marido e esposa, em que um marido possui uma esposa e apenas uma esposa e uma esposa possui um marido e apenas um marido, esta cardinalidade é representada como 1,1 entre os parênteses. A segunda relação é entre uma entidade pai e uma entidade filho, a entidade pai pode ter nenhum ou vários filhos, porém a entidade filho deverá ter somente um pai e obrigatoriamente. Neste caso a representação pai e filho ocorre com os valores 0, n enquanto a representação filho e pai ocorre com os valores 1, 1. Por último o exemplo mostra a relação entre tio e sobrinho, em que o tio poderá ter nenhum ou vários sobrinhos, da mesma forma o sobrinho poderá ter nenhum ou vários tios, assim essa relação tem como representação os valores 0, n.

Na Figura 2.7, a leitura da cardinalidade é feita da seguinte maneira, na sequência dos relacionamentos:

• Um marido tem no mínimo uma esposa e no máximo uma esposa. Uma esposa tem no mínimo um marido e no máximo um marido.
• Um filho tem no mínimo um pai e no máximo um pai. Um pai tem no mínimo nenhum filho e no máximo muitos filhos.
• Um tio pode ter nenhum ou pode ter muitos sobrinhos. Um sobrinho pode ter nenhum ou ter muitos tios.

Com isso, finalizamos nossa visão geral, sobre o modelo conceitual utilizando diagrama entidade relacionamento.

Uma vez compreendido o conceito de banco de dados, bem como de modelo conceitual, a partir de agora veremos mais detalhes sobre o modelo lógico.

Aprendemos que o modelo conceitual deve estar compreensível ao usuário, bem como para o profissional da área de negócios. O modelo lógico por sua vez não será compreensível para o usuário comum, porém reflete exatamente a estrutura de como o banco de dados será armazenado e deverá ser compreensível para o programador.

No entanto, antes de aprofundar na criação do modelo, é importante compreender como um banco de dados se comporta. Existem diversos tipos de SGBDs, uns que armazenam estruturas de grafos, outros arquivos JSON e o mais consolidado, o sistema gerenciador de banco de dados relacional (SGBDR).

Ao utilizar um SGBDR, o banco de dados será estruturado em tabelas, que estão conectadas por meio de relacionamentos. Cada linha de uma tabela, denominada tupla, armazena um registro cadastrado em um banco de dados. As colunas são denominadas campos e têm o mesmo significado que um atributo no modelo relacional.

#PraCegoVer: Tem-se uma tabela de empregados onde tem-se 4 colunas. A coluna código do empregado, a coluna nome de empregado, a coluna código do departamento e coluna categoria funcional. Estas colunas chamam-se de atributos. Tem-se 4 exemplos de cadastramento de funcionários nesta tabela. O E5 como código do empregado, como nome: Souza, código do departamento D1 e a categoria funcional C5. N alinha abaixo tem-se o empregado E3, com o nome Santos, com o código do departamento de D2 e com a categoria funcional se C5. As linhas chamam-se de tupla.

Desenvolvendo o Modelo

Como na estrutura relacional, o elemento principal do modelo lógico é a tabela, que é composta por campos e cada campo tem um tipo determinado.

#PraCegoVer: Tem-se o modelo lógico da tabela aluno onde tem a identificação do aluno como interger not null; o atributo nome como varchar 100 not null; o CPF como varchar 11 not null e a data de nascimento como date not null.

Na Figura 2.9, apresenta-se uma tabela modelada para armazenar dados de um aluno, em que o campo id_aluno é uma chave primária, isto significa que é o campo que identifica, unicamente, cada registro armazenado. O campo nome é do tipo texto e poderá ter no máximo 100 caracteres. O campo cpf, como não é um número inteiro e sim uma sequência de números, será armazenado como texto de até 11 caracteres.

Os tipos de dados podem variar com o SGBDR utilizado, tomando como base o PostgreSQL, os tipos de dados serão conforme apresentado a seguir:

• Integer: números inteiros;
• Numeric: números com ponto flutuante;
• Varchar: textos até 255 caracteres;
• Text: textos longos;
• Date: valores de data;
• Time: valores de hora;
• Timestamp: valores com data e hora;

Criando Relacionamento

Assim como as entidades no modelo relacional, as tabelas também se relacionam. No entanto, para criar o relacionamento entre tabelas, serão utilizadas as chaves primárias e chaves estrangeiras, que irão se ligar a estas.

Uma chave estrangeira é uma coluna ou uma combinação de colunas, cujos valores aparecem necessariamente na chave primária de uma tabela. A chave estrangeira é o mecanismo que permite a implementação de relacionamentos em um banco de dados relacional (HEUSER, 2009, p. 89).

Portanto, cada chave estrangeira se ligará a uma chave primária, compondo assim um relacionamento. A Figura 2.10 apresenta como as chaves se comportam dentro de um relacionamento.

#PraCegoVer: Esta figura tem acima a tabela “Departamento” com 2 atributos: “código do departamento” e “nome do departamento”, aonde a chave primária é o código do departamento. Nesta tabela tem-se como exemplo departamento com o código departamento D1 e como nome do departamento compras; o código de departamento D2 com o nome engenharia; e o D3 com o nome vendas. A tabela abaixo é de empregados. Onde temos os atributos código do empregado, nome do empregado, código do departamento, categoria funcional e o CPF onde temos o código do empregado como uma chave primária e também o CPF como uma chave primária. Nesta tabela tem-se 4 exemplos. O primeiro com o código do empregado E1, com o nome Souza, com o código de departamento D1, sem categoria funcional e com o CPF 132 121 331 20.

Utilizando como exemplo um trecho do modelo do sistema acadêmico a Figura 2.11 apresenta um modelo lógico. O grande destaque está no id_professor, note que em professor existe um campo id_professor que é a chave primária. Note que em disciplina há um outro campo chamado id_professor, esse campo conecta disciplina do professor responsável, o id_professor na tabela disciplina é denominado chave estrangeira.

#PraCegoVer: Nesta figura temos 2 tabelas uma chamada disciplina e outra chamada professor. Na tabela disciplina tem-se os atributos identificação da disciplina, nome, carga horária e identificação do professor. Tem-se como chave primária a identificação da disciplina e como chave secundária a identificação do professor. Na tabela ao lado que é a tabela professor tem-se os atributos identificação do professor, nome, CPF e data de nascimento e vê-se uma ligação entre o atributo identificação da disciplina da tabela disciplina e a identificação do professor na tabela professor.

Portanto, até este momento vimos o conceito de modelo conceitual e lógico, aprendendo a criar os principais componentes de cada modelo.

O modelo físico é quando o seu banco de dados passa a existir fisicamente. Para que o modelo físico exista é necessário o papel do SGBD. Conforme você aprendeu, os usuários e aplicações não se conectam diretamente com os dados, mas sim ao SGBD e este sim fica responsável de manipular os dados.

Pode-se dizer que os SGBDRs falam um idioma só, uma linguagem de banco de dados denominada SQL (Structured Query Language), linguagem de consulta estruturada. Ainda que cada SGBDR possa ter sua particularidade, nessa linguagem existe um padrão para que os comandos sejam iguais.

A SQL pode ser dividida em dois tipos principais, a DDL ( Data Definition Language - Linguagem de Definição de Dados) e DML ( Data Manipulation Languag e - Linguagem de Definição de Dados), explanadas em detalhes nos próximos tópicos.

DDL

A DDL ( Data Definition Language - Linguagem de Definição de Dados) será o tipo de SQL utilizado para atuar na estrutura de um banco de dados. Ou seja, utilizando DDL, criaremos: criar tabela, excluir tabela, adicionar campo, remover campo, entre outras alterações que se refiram à definição, ou seja, à estrutura de uma tabela.

Tomando como exemplo a Figura 2.11, para criar um banco de dados e essas duas tabelas em um SGBD, é necessário executar o seguinte comando:

Portanto, o comando create seguido de um nome indica a criação de uma tabela. A cada linha um novo campo é adicionado, separado dos demais por vírgula, o tipo de dados vem na sequência, bem como das suas características. Por exemplo, o campo id_disciplina, que é uma chave primária, vem seguido da declaração PRIMARY KEY.

Ao criar uma chave estrangeira em disciplina, primeiro indica qual campo da tabela local, ou seja, com FOREIGN KEY (id_professor), que se refere ao campo id_professor da tabela professor. E com comando references é feita a ligação com a tabela professor e a chave primária id_professor.

DML

A DML (Data Manipulation Language), linguagem de manipulação de dados, é a linguagem que permite manipular os dados em si. A partir do momento que a estrutura de uma tabela em um banco de dados já foi criada, é possível inserir e manipular dados através de comandos DML, que são os seguintes.

• Insert : comando utilizado para inserir registros em uma tabela. Neste comando é passada a sequência dos campos e dos valores a serem inseridos entre parênteses.
  ○ Exemplo de inserir professor e disciplina

• Select : comando utilizado para visualizar os dados inseridos, pode ou não utilizar parâmetros através da condição where.
  ○ Exemplos de consulta a professores

• Update : comando utilizado para atualizar os registros. É muito importante vir seguido da condição where, caso a mesma não exista a condição TODOS os registros serão atualizados.
  ○ Exemplo de atualizar professor

• Delete : comando utilizado para deletar os registros. É muito importante vir seguido da condição where, caso a mesma não exista a condição TODOS os registros serão excluídos.
  ○ Exemplo de deletar professor

Durante esta unidade você aprendeu os comandos necessários para criar um banco de dados, tabelas, bem como para inserir e manipular os dados. As instruções SQL são muitas, mas com o que foi visto já é possível criar um programa que se conecta com o banco de dados.