Aula 1 Lógica de programação e algoritmos, Notas de aula de Linguagem de Programação

Baixe Aula 1 Lógica de programação e algoritmos e outras Notas de aula em PDF para Linguagem de Programação, somente na Docsity!

BANCO DE DADOS

AULA 1

Prof. Ricardo Sonaglio Albano e Profª. Silvie Guedes Albano

CONVERSA INICIAL

Fundamentos de Banco de Dados

O tema Banco de Dados é um conhecimento que deve ser adquirido pelos profissionais da área de tecnologia, pois basicamente todas as informações, de uma forma ou outra, encontram-se armazenadas em Bancos de Dados. Neste estudo, abordaremos os conceitos e as técnicas que você precisará para ingressar no universo de Banco de Dados Relacional, abrangendo desde os aspectos de modelagem até a utilização da linguagem Structured Query Language (SQL) para a manipulação das informações. Apresentaremos e discutiremos tópicos que o ajudarão a desenvolver habilidades para a interpretação e análise de informações, ingressando, assim, em um processo de reflexão sobre o desenvolvimento de um Banco de Dados e as melhores práticas de atuação como profissional da área. Aliando a teoria e a prática, apoiaremos você em cada passo desse caminho, acompanhando-o no processo de construção de uma base de dados e discutindo sobre as melhores abordagens, metodologias existentes, suas formas de aplicação e implementação em soluções práticas no desenvolvimento. Nesta primeira etapa, apresentaremos os principais conceitos sobre o Sistema Gerenciador de Banco de Dados (SGBD), os tipos de modelos de dados, as etapas da modelagem de dados, a construção do Modelo Entidade- Relacionamento (MER) e a influência da cardinalidade exercida sobre o modelo de dados. Vale salientar que desenvolver uma forte base conceitual sobre Banco de Dados servirá de suporte fundamental na construção prática de projetos de Banco de Dados. São conceitos que você deverá manter em sua memória, pois com certeza os utilizará frequentemente no dia a dia de sua profissão. Bons estudos e sucesso!

TEMA 1 – CONCEITOS, DEFINIÇÕES E MODELOS

Em todas as organizações existe a necessidade do armazenamento de informações. Além de uma forma adequada para definir o armazenamento dessas informações, os usuários realizam consultas em determinado conjunto de dados, atualizam ou modificam a estrutura dos dados e eliminam informações não necessárias.

1.2 Banco de Dados (BD)

Existem diversos conceitos utilizados para definir um Banco de Dados. Vejamos alguns deles:

• Coleção de dados persistentes usados pelos sistemas de aplicação de determinada empresa;
• Conjunto de dados inter-relacionados representando informações de um domínio específico;
• Sistema que registra e mantém dados baseados em computador;
• Sistema computadorizado de armazenamento de registros, cujo objetivo é armazenar informações e permitir aos usuários buscar e atualizar essas informações quando necessário;
• Todo o conjunto de dados que segue determinado modelo de dados. Resumindo, um Banco de Dados (BD) é o local onde são armazenados os dados de uma aplicação. Exemplo de um Banco de Dados: sistema de delivery, em que a empresa deseja armazenar as informações sobre os clientes, produtos, entregadores, restaurantes, entre outros. Cada um desses elementos serão as entidades básicas sobre as quais a aplicação de delivery precisará registrar informações.

1.2.1 Modelos de Banco de Dados

É a representação do Banco de Dados, demonstrando a relação existente entre os dados. Os modelos de Banco de Dados são:

• Hierárquico;
• Rede;
• Orientado a objetos;
• Relacional;
• NoSQL ou não-relacional.

1.2.1.1 Modelo hierárquico

O Sistema de Banco de Dados Hierárquico ( Hierarquical Database System – HDS) surgiu na década de 1960 com a primeira linguagem de Banco

de Dados, conhecida como DL/I, desenvolvida pela IBM e a North American Aviation. Nesse modelo os dados são armazenados em estruturas no formato de árvore. Cada estrutura de dados parte de um nodo raiz (nó) e se ramifica criando relações pai-filho com outras classes de dados, gerando relações de um para muitos elementos. A desvantagem está na rigidez da estrutura de dados, em que, no caso de alterações da classe principal ou de classes dependentes, obrigaria que fosse refeito todo o Banco de Dados.

1.2.1.2 Modelo de rede

Também conhecido como Sistema de Banco de Dados em Rede ( Network Database System – NDS), esse modelo surgiu entre as décadas de 1960 e 1970 como uma extensão do modelo hierárquico, adicionando recursos para criação de mais de uma relação pai-filho e estabelecendo relações entre os seus elementos. Esse modelo possui a vantagem de uma pesquisa mais rápida e flexível, pois não depende de um único nó raiz como vetor de inicialização da pesquisa. Apesar disso, o modelo de rede ainda apresenta os problemas relatados no modelo anterior no que se refere à relação ao projeto de estrutura do modelo hierárquico. Qualquer alteração feita em uma classe de dados implicaria na criação de uma nova estrutura para suportar àquela alteração. Nesse caso, as relações entre os registros são feitas por meio de ponteiros que armazenam endereços de memória, indicando os endereços em que os dados realmente se encontram armazenados. O modelo em rede trabalha com registros vinculados uns aos outros, gerando conjuntos de dados.

1.2.1.3 Modelo orientado a objetos

Incorpora as características da metodologia de desenvolvimento orientado a objetos com os conceitos de Sistema Gerenciador de Banco de Dados (SGBD). Nesse modelo de dados, a informação é organizada e, consequentemente, armazenada sob a forma de objetos, inclusive com a

simples, qualquer formato de dados. Dessa forma, possibilita-se não só um desenvolvimento mais rápido, mas também uma melhor performance no tratamento de volumes muito grandes de requisições, gerando respostas mais rápidas;

• Escalabilidade: são projetados para expandir seus recursos de forma horizontal, isto é, adicionando máquinas comuns ( nodes ) a estrutura já disponível, bem mais baratas que os caros servidores. Consequentemente, expande-se sua capacidade para suportar o aumento de tráfego, sua disponibilidade no recebimento de requisições e aumenta a performance em tempo de execução e resposta;
• Alta performance: focado na otimização de modelos de dados e padrões de acesso, gerando maior performance em comparação a outros modelos de dados. No NoSQL existem quatro tipos principais de modelos de dados: chave- valor, documento, gráfico e família de colunas. Vale salientar que existem situações em que sua aplicação não é considerada a mais adequada e, dessa forma, o Banco de Dados relacional é a melhor alternativa.

TEMA 2 – SISTEMA GERENCIADOR DE BANCO DE DADOS (SGBD) E

APLICAÇÕES DE BANCO DE DADOS

Entre os dados armazenados fisicamente no disco rígido e os usuários do sistema, que manipulam esses dados, existe uma camada de software conhecida como Sistema Gerenciador de Banco de Dados (SGBD). O Sistema Gerenciador de Bancos de Dados é a interface entre os dados de baixo nível, armazenados em um Banco de Dados, e os usuários e as aplicações, que desejam acessar e manipular esses dados. O sistema de Banco de Dados é um sistema de manutenção de registros por computador e, para tanto, possui diversos recursos à disposição do usuário, possibilitando a realização de várias operações, como por exemplo:

• Adição, remoção e atualização de tabelas no Banco de Dados;
• Inserção de novos dados;
• Recuperação, atualização e exclusão de dados.

Como objetivos, o SGBD deve:

• Ocultar dos usuários os detalhes mais técnicos de funcionamento do Banco de Dados, também conhecido como abstração de dados ;
• Prover independência de dados às aplicações (estrutura física de armazenamento e a estratégia de acesso). Destacamos alguns SGBDs amplamente utilizados: DB2 (IBM), Microsoft SQL Server, Oracle, MySQL, PostgreSQL, entre outros.

2.1 Características de um SGBD

Um SGBD deve ter algumas características que são essenciais para o seu funcionamento, tais como:

• Controle de redundância: consiste no armazenamento de uma mesma informação em locais diferentes, provocando duplicidade e possíveis inconsistências. Em um Banco de Dados, as informações encontram-se armazenadas em um único local, não existindo duplicação dos dados;
• Compartilhamento dos dados e concorrência: o SGBD deve incluir o controle de concorrência no acesso aos dados, possibilitando o compartilhamento dos dados e garantindo que, se vários usuários realizarem operações de atualização sobre um mesmo conjunto de dados, o resultado dessas operações será correto;
• Controle de acesso: o SGDB deve disponibilizar recursos para o gerenciamento de acesso dos usuários, definindo permissões, como, por exemplo, um usuário poderá ter acesso total, enquanto outro usuário terá apenas acesso de leitura de dados;
• Controle de transações: uma transação é um conjunto de operações sobre o Banco de Dados que devem ser executadas integralmente e sem falhas ou interrupções;
• Possibilidade de múltiplas interfaces: um SGBD pode ser acessado por diversas interfaces diferentes (aplicação WEB, aplicativo mobile, entre outros). Logo, o SGBD deve garantir que todos tenham acesso aos dados da mesma forma;
• Restrições de integridade: deve garantir que as regras de integridades definidas no momento da criação do Banco de Dados sejam aplicadas

1. Hardwares: dispositivos em que as informações são armazenadas fisicamente;
2. SGBD: software que permite o acesso dos usuários às informações armazenadas no Banco de Dados;
3. Aplicações: softwares que realizam requisições para o SGBD com a finalidade de interagir com as informações do Banco de Dados;
4. Usuários: estão divididos em três categorias: o Programador de aplicações – responsável pela definição dos programas de aplicação que utilizam o Banco de Dados; o Administrador de Banco de Dados ou DBA – responsável pelo controle e gerenciamento; o Usuário final – interage com o sistema a partir de um computador conectado ao Banco de Dados.

Figura 2 – Representação de um sistema de Banco de Dados

Fonte: Albano; Albano, 2022.

2.4 Administrador de Banco de Dados (DBA)

Podendo ser um ou mais responsáveis pela tarefa de gerenciamento do Banco de Dados, esses profissionais são responsáveis pela autorização de acesso ao Banco de Dados para os demais usuários, coordenação e monitoração do uso, ou seja, são eles que coordenam todas as atividades do sistema de Banco de Dados e possuem conhecimento sobre os recursos de informação da empresa e suas necessidades. Suas funções incluem:

• Definição do Banco de Dados;
• Estrutura de armazenamento e definição de acesso aos dados;
• Esquema físico e organização dos dados;
• Conceder acesso aos usuários;
• Cuidar da integridade dos dados;
• Acompanhar o desempenho do Banco de Dados;
• Atividades de manutenção e backups.

TEMA 3 – MODELAGEM DE DADOS

O objetivo da modelagem de dados é a representação do cenário observado e suas necessidades, analisando, documentando, normalizando e detectando como as informações relacionam-se entre si, bem como fornecendo processos de validação que nos permitem avaliar a veracidade dos modelos desenvolvidos. Um Banco de Dados pode ser descrito ou modelado em vários níveis de abstração, sendo, assim, definidos três modelos básicos:

1. Modelo conceitual;
2. Modelo lógico;
3. Modelo físico. Antes de iniciar a construção de um Banco de Dados é essencial a existência do projeto desse banco. Os modelos ajudam a demonstrar graficamente o Banco de Dados que será construído. Um modelo de dados é a descrição formal de um Banco de Dados.

3.1 Projeto de Banco de Dados

Todo bom sistema de Banco de Dados deve apresentar um projeto com objetivo de organizar as informações e utilizar técnicas para promover a criação de um sistema que apresente boa performance, além de facilitar o processo de manutenção que porventura possa ser necessária. O projeto de Banco de Dados consiste em quatro etapas:

1. Análise de requisitos;
2. Modelagem conceitual;
3. Modelo lógico;

• Somente as entidades e campos principais;
• Independente da implementação e do SGBD;
• Descrição mais abstrata do Banco de Dados;
• Ponto de partida para o projeto de um Banco de Dados. Uma das técnicas mais utilizadas entre os profissionais da área é a abordagem Entidade-Relacionamento (ER), em que o modelo é representado por meio do Modelo Entidade-Relacionamento (MER).

Figura 4 – Exemplo de Modelo Entidade-Relacionamento (MER)

Fonte: Albano; Albano, 2022.

O modelo acima nos apresenta informações sobre as entidades Cliente e Cidade, em que para cada cliente será armazenado seu código de identificação, nome, endereço e código da cidade onde reside. Para cada cidade armazenaremos o código, o nome da cidade e a unidade federativa correspondente. Vale salientar que, no exemplo acima, a relação ou associação existente entre as duas entidades se baseia na premissa que UM cliente reside apenas em UMA cidade, mas UMA cidade poderá ter NENHUM ou VÁRIOS clientes residentes. Essa relação é denominada cardinalidade e será abordada com mais detalhes em um próximo tópico desse material de estudo.

3.3 Modelo lógico

Nesta fase, descrevemos o Banco de Dados no nível do SGBD, ou seja, todo modelo considerará as limitações e as características particulares do tipo de tecnologia presente no Banco de Dados escolhido. Suas características são:

• Deriva do modelo conceitual;
• Define as chaves primárias das entidades;
• Normalização até a 3ª forma normal;

• Adequação ao padrão de nomenclatura;
• Relações e atributos documentados;
• Dependente do SGBD. O modelo lógico do Banco de Dados relacional deve definir quais as relações (tabelas) e quais os atributos que compõem as relações, bem como os tipos de dados (número inteiro, data, cadeia de caracteres, entre outros) que serão armazenados nesses atributos. Baseado no exemplo anterior, podemos definir o modelo lógico conforme:
• Cliente: codigo (integer), nome (varchar), endereco (varchar) e codcidade (integer);
• Cidade: codigo (integer), descricao (varchar) e UF (char). É importante ressaltar que os detalhes internos de armazenamento não são descritos no modelo lógico, uma vez que essas informações fazem parte do modelo físico, que nada mais é que a tradução do modelo lógico para a linguagem do software escolhido para implementar o sistema.

Figura 5 – Exemplo de modelo lógico

Fonte: Albano; Albano, 2022.

3.4 Modelo Físico

Considera os limites impostos pelo Sistema Gerenciador de Banco de Dados (SGBD) e pelos requisitos não funcionais dos programas que acessam os dados. Características:

• Elaborado a partir do modelo lógico;

formar as tabelas do Banco de Dados. Por exemplo, informações sobre clientes, produtos, entregadores, restaurantes, entre outros;

• Campo: características particulares de cada entidade. Por exemplo, o cliente possui nome, data de nascimento, cidade onde reside, entre outras informações. O conjunto de informações contidas nos campos formam o que chamamos de registro;
• Relacionamento: representa a associação entre duas ou mais entidades. Por exemplo, o cliente reside em determinada cidade.

4.1 Entidade

Como já mencionamos, a entidade no modelo conceitual representa um objeto do qual desejamos armazenar as informações que serão utilizadas em uma aplicação. Por exemplo, o sistema de delivery necessita armazenar informações sobre os clientes. Como existem diversas informações sobre cada cliente, nesse caso, se faz necessário criar uma entidade com a função de representar esse objeto.

4.1.1 Tipos de entidades

De acordo com a estrutura da chave primária e baseado no grau de dependência que uma entidade possui em relação às demais entidades do modelo, uma entidade poderá ser enquadrada como:

• Entidade fundamental;
• Entidade associativa;
• Entidade fraca. Vale salientar que alguns dos conceitos citados acima serão esclarecidos após o aprofundamento dos conceitos do MER.

4.1.1.1 Entidade fundamental

É a entidade que possui chave primária simples, ou seja, a sua chave primária não é composta pela chave primária de nenhuma outra entidade. Dessa forma, a entidade fundamental não necessita da existência de qualquer outra entidade para existir, pois é independente.

Por exemplo, entidades Cliente, Produto, Entregador, Restaurante, entre outras.

4.1.1.2 Entidade associativa

É a entidade definida a partir da simplificação de um relacionamento de muitos para muitos entre duas ou mais entidades. Por exemplo, em um relacionamento entre a entidade Pedido e a entidade Produto, ocorre a seguinte situação: um pedido pode conter um ou vários produtos e um produto pode ser vendido em nenhum ou vários pedidos. Com esse tipo de relacionamento surge a necessidade da criação de uma nova entidade (explicaremos melhor esse tipo de relacionamento no tópico sobre cardinalidade). Essa nova entidade poderá ser chamada de ItemPedido e nela serão armazenados alguns campos específicos, tais como quantidade vendida, valor do produto, desconto do produto, entre outros.

4.1.1.3 Entidade fraca

Essa entidade caracteriza-se pela dependência existencial, isto é, a entidade depende de uma outra entidade para poder existir no modelo. Em casos em que exista a entidade fraca, tanto o relacionamento quanto a entidade deverão serem representados com borda dupla. Por exemplo, em uma relação entre as entidades Funcionário e Dependente, sabemos que um funcionário poderá possuir nenhum ou vários dependentes. Dessa forma, a entidade Dependente apenas existe por causa da entidade Funcionário. Se eliminarmos a entidade Funcionário, consequentemente, a entidade Dependente desaparecerá devido a sua dependência.

Figura 7 – Exemplo de entidade fraca

Fonte: Albano; Albano, 2022.

Figura 9 – Exemplo de representação de uma entidade

Fonte: Albano; Albano, 2022.

4.1.5 Estudo de caso

Para aprimorar os conceitos, vamos implementar passo a passo um estudo de caso sobre uma rede de restaurantes que decidiu ter um aplicativo de delivery. O restaurante “Comer é Bom Demais” forneceu, inicialmente, as seguintes regras de negócio:

1. O restaurante possui diversas filiais espalhadas pelo território nacional, podendo ter mais de uma filial na mesma cidade. Essas informações devem estar devidamente cadastradas.
2. O restaurante possui vários funcionários.
3. Os pedidos são entregues por entregadores autônomos.
4. O aplicativo deverá possuir produtos.
5. Os pedidos referentes a cada restaurante deverão ser devidamente armazenados.
6. Para fazer um pedido no sistema de delivery, o cliente deverá estar previamente cadastrado. Vale ressaltar que, ao longo do desenvolvimento do modelo, serão incluídas novas regras de negócio com o objetivo de aprofundar e aplicar os conceitos aqui discutidos. Para começar, vamos definir as entidades que representaram cada objeto do mundo real da empresa de delivery, baseando-se sempre nas regras de negócio já conhecidas. Avalie as regras de negócio perguntando-se sobre quais objetos ou itens têm características ou informações próprias a serem armazenadas. Pensando dessa forma, já podemos identificar as seguintes entidades:

• Como a empresa atua em âmbito nacional, seria importante armazenarmos informações sobre os estados e as cidades ;

• O quadro de funcionários dessa empresa também precisa ser contemplado, pois a empresa necessita dessas informações;
• Clientes , restaurantes , entregadores e produtos seguem a mesma linha de raciocínio;
• Quanto a movimentação dos pedidos , a empresa precisa ter um controle do que foi vendido, para quem foi vendido e qual restaurante vendeu. Perceba que cada objeto que armazena informações foi definido como uma entidade. É possível que você tenha encontrado outras entidades que não foram listadas nesse momento. Não se preocupe, durante a evolução do modelo é comum a inclusão e a exclusão de entidades até chegarmos ao modelo ideal. Isso faz parte do processo de construção do projeto de Banco de Dados. Baseado nas entidades que já descobrimos, vamos analisar qual a relação que cada uma pode possuir com as demais:
• Restaurante: o Possui várias filiais que estão instaladas em diferentes cidades; o Cada filial receberá vários pedidos por meio do aplicativo; o Possui muitos funcionários em cada filial;
• Cliente: o Realiza um pedido por meio do aplicativo; o Reside em uma cidade;
• Funcionário: o Faz parte do quadro de funcionários de uma das filiais; o Reside em uma cidade;
• Entregador: o Realiza as entregas dos pedidos; o Está locado em uma cidade;
• Pedido: o Precisa-se manter as informações sobre quem fez o pedido, para qual filial e qual(is) foi(ram) o(s) produto(s) escolhido(s);
• Produto: o Sempre será referenciado dentro de um pedido;
• Cidade: o Pertence a um estado;
• Estado: