MODELAGEM DE SOFTWARE

Seite 1

Calendário

Encontro Plenária - 11/05/2024 - 9h às 11h50

Encontro Conecta - 25/05/2024 - 9h às 11h50

Encontro Talk - 08/06/2024 - 9h às 11h50

AVALIAÇÕES

A1 - 13 de Maio à 03 de Junho

Solicitação para Recurso A1 - 06 de Junho à 10 de Junho

Solicitação para 2ª Oportunidade A1 - 06 de Junho à 10 de Junho

A2 - 04 de Junho à 07 de Junho

Solicitação para Recurso A2 - 07 de Junho à 11 de Junho

Solicitação para 2ª Oportunidade A2 - 07 de Junho à 11 de Junho

A3 - 15 de Maio à 12 de Junho

Aplicação de 2ª Oportunidade A1 - 14 de Junho à 17 de Junho

Aplicação de 2ª Oportunidade A2 - 18 de Junho à 21 de Junho

Avaliação Integrada (AI) - 26 de Junho à 27 de Junho

Critérios

As Avaliações das Unidades Curriculares do E2A Digital são divididas em A1, A2 e A3 e obedecem aos seguintes Critérios de Avaliação:

A1 - Avaliação realizada on-line no Ambiente Virtual de Aprendizagem. A A1 vale 30 (trinta) pontos e será composta por uma questão dissertativa. Ao clicar em iniciar, o estudante precisa finalizar em 4h.

A2 - Avaliação realizada on-line no Ambiente Virtual de Aprendizagem. A A2 vale 30 (trinta) pontos e será composta por questões objetivas, cada uma delas com 5 (cinco) alternativas (A, B, C, D e E), sendo apenas uma das alternativas a resposta correta. Ao iniciar, o estudante precisa finalizar em 3h.

A3 - Avaliação realizada on-line no Ambiente Virtual de Aprendizagem. A A3 vale 40 (quarenta) pontos e é dissertativa. Ao iniciar a avaliação, não é contabilizado tempo no Ulife, desde que atenda o prazo para realização indicado no calendário.

A1 (30%) + A2 (30%) + A3 (40%) = 100%

São considerados aprovados os estudantes que obtiverem desempenho igual ou superior a 70% (70 pontos).

IMPORTANTE:

>>> Caso o estudante não consiga realizar as avaliações A1 ou a2, pode estar elegível a fazer a avaliação em segunda oportunidade. Para entender mais, acesse o regulamento da avaliação e se informe.

>>> Aqueles estudantes que não alcançaram, no mínimo, 70% de aproveitamento (necessário para aprovação em cada Unidade Curricular), poderão realizar a AI (Avaliação Integrada).

Sendo assim, a AI é um instrumento de avaliação com finalidade de propiciar uma recuperação. Ao realizar a AI, o estudante tem a possibilidade de substituir o menor desempenho (A1 ou A2), representando 30% da nota final. A avaliação A3 não tem recuperação.

>>> A realização da atividade Pratique (proposta na Unidade 2) e a participação nos fóruns com o tutor não são avaliativos e, portanto, não são considerados para a composição do desempenho final.

>>> Cada Unidade Curricular do E2A Digital possui três encontros digitais ao vivo com um professor especialista. Estes momentos são chamados de Plenária, Conecta e Talk. A participação dos estudantes nos encontros ao vivo não é avaliativa e, portanto, não é considerada para a composição do desempenho final.

Seite 2

INTRODUÇÃO (DL)

Unidade 01 - Especificação de Requisitos Tradicionais

Na primeira unidade, você vai aprender os conceitos de requisitos, bem como as suas influências no processo de desenvolvimento de sistemas. Ao final, você estará apto a especificar requisitos funcionais e não funcionais de acordo com as necessidades de usuários e clientes.

Unidade 02 - Técnicas de Levantamento de Requisitos

A segunda unidade aborda um conjunto de técnicas para apoiar os analistas de sistemas a levantar e a elicitar requisitos junto a seus usuários e clientes. Assim, você irá aprender como cada técnica funciona e a selecionar quais delas usar em um dado projeto de desenvolvimento de software.

Unidade 03 - Especificação de Requisitos Ágeis

Esta unidade apresenta formas de especificarmos requisitos em ciclos de desenvolvimento que seguem a filosofia ágil, em que o volume de documentos é reduzido para favorecer a interação humana. Desse modo, você aprenderá como especificar requisitos em contextos ágeis.

Unidade 04 - Banco de Dados

Banco de Dados, em uma visão geral, é o tema tratado nesta unidade. Logo, ao final dela, você compreenderá como funciona a abstração do armazenamento de dados em sistemas.

Unidade 05 - Modelo Conceitual de Dados

Esta unidade aborda como abstrair e representar modelos de dados em nível de análise. Nela você vai aprender a criar modelos conceituais de banco de dados de acordo com os propósitos das necessidades do sistema de informação.

Unidade 06 - Modelo Lógico de Dados

Esta unidade aborda como abstrair e representar modelos de dados em nível de projeto (design) da solução. Nela você vai aprender a criar modelos lógicos de banco de dados de acordo com os propósitos das necessidades do sistema de informação.

Unidade 07 - Diagramas UML

Nesta unidade, vamos aprender a utilizar a linguagem gráfica UML (Unified Modeling Language) para modelar a estrutura e o comportamento de sistemas na abordagem orientada a objetos. Ao final, você estar apto a modelar sistemas orientados a objetos em nível de análise e projeto (design).

Unidade 08 - Modelo Físico de Dados

Esta unidade aborda como abstrair e representar modelos de dados em nível físico (implementação) da solução. Nela você vai aprender a criar modelos físicos de banco de dados de acordo com os propósitos das necessidades do sistema de informação.

Seite 3

ESPECIFICAÇÃO DE REQUISITOS TRADICIONAIS

Requisitos de um sistema são descrições do que o software deve fazer, os serviços que devem ser fornecidos por esse sistema e as suas restrições operacionais. Os requisitos descrevem o que o software deve fazer e o que não deve fazer sem dizer como fazer (SOMMERVILLE, 2011).

Dentro da área de conhecimento "requisitos de software", obtemos diferentes definições de requisitos, sendo os principais tipos: produto versus processo, funcionais versus não funcionais, e propriedades.

Nessa área, também identifica-se a importância dos requisitos quantificáveis e diferenciam-se sistemas e requisitos de software.

Requisito de software é classificado como uma AÇÃO que o software deve executar que possui características e condições próprias para automatizar um processo de negócio de cliente

De acordo com o IEEE, define-se requisitos de software como:

Uma condição ou uma capacidade de que o usuário necessita para solucionar um problema ou alcançar um objetivo;

Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema ou componente do sistema, para satisfazer um contrato, um padrão, uma especificação ou outros documentos impostos formalmente;

Uma representação documentada de uma condição ou capacidade (on-line).

Requisitos funcionais

Os requisitos funcionais descrevem explicitamente as funcionalidades (funções que o sistema deve realizar) e os serviços do sistema. Segundo Sommerville (2007), são declarações de serviços que o sistema deve prover, descrevendo o que o sistema deve fazer;

Pfleeger (2004) afirma que um requisito funcional descreve uma interação entre o sistema e o seu ambiente. Para exemplificar, imagine um sistema de uma biblioteca, que deve manter registro de todos os materiais que há nela (livros, CD's, séries, jornais, revistas etc.), bem como deve permitir que o usuário busque um item por seu título, autor ou outro.

Então, os requisitos funcionais abrangem os serviços que o sistema deve fornecer, e assim como destaca Sommerville (2007), trata-se de como o sistema deve reagir a entradas específicas, de como o sistema deve se comportar em situações específicas e o que o sistema não deve fazer.

Para Pohl e Ruppy (2012), é um requisito relacionado ao resultado de algum comportamento a ser fornecido por uma função do sistema.

Os requisitos funcionais estão relacionados às funções de negócios do dia a dia que os usuários executam no sistema, como, por exemplo, o usuário deve ser capaz de pesquisar em todo o conjunto inicial de um banco de dados.

Requisitos funcionais podem ser descritos por meio de diagramas de casos de uso e de especificação de casos de uso, mas também podem ser descritos na forma declarativa.

Acompanhe os exemplos:

cadastrar clientes;

fazer análise de crédito;

fazer uma transação com banco de dados;

cadastrar um registro de atendimento;

imprimir relatório etc.

Requisitos não funcionais

Os requisitos chamados de não funcionais definem propriedades e restrições de um sistema, isto é, a complexidade de um software é determinada, portanto, por sua funcionalidade (o que o sistema faz) e por requisitos gerais que são parte do desenvolvimento do software, como custo, desempenho, confiabilidade, manutenibilidade, portabilidade, custos operacionais, entre outros.

Também conhecidos como RNF, suplementares ou de qualidade, os requisitos não funcionais declaram as características que o sistema deve possuir e que estão relacionadas às suas funcionalidades, ou seja, fixam restrições sobre como os requisitos funcionais serão implementados, o que torna difícil, muitas vezes, uma distinção clara entre eles.

Como exemplo de características que o sistema deve possuir, temos: performance, portabilidade, segurança, usabilidade, qualidade do serviço (QoS), confidencialidade, confiabilidade, portabilidade, precisão, integridade, eficiência, entre outras.

Os requisitos não funcionais podem ser mais severos e críticos que os requisitos funcionais; isso quer dizer que, se eles não forem atendidos, então, o sistema não serve: se não satisfaz, o sistema é inútil. Esses tipos de requisitos são as causas das principais insatisfações dos usuários com relação ao software.

Também são classificados em três tipos, sendo eles: requisitos do produto final, requisitos organizacionais e requisitos externos. Os requisitos do produto final referem-se a como o produto deve se comportar, sua velocidade de execução, confiabilidade, ente outros. Os requisitos organizacionais dizem respeito à consequência de políticas e procedimentos organizacionais que devem ser seguidos. Os requisitos externos são concernentes a fatores externos ao sistema e ao processo de desenvolvimento.

Abordagens orientadas a produto: avaliam o grau em que o produto final atende a determinados RNFs.

O sistema é avaliado pelo grau em que ele atende a determinado requisito não funcional.

Propõe o uso de métricas para medir a qualidade do sistema.

Existem várias propostas na literatura.

Abordagens orientadas a processo: integram o esforço de descrever e atender RNFs durante o processo de desenvolvimento.

Em vez de avaliar a qualidade do produto final, a ênfase é dada a orientar o processo de desenvolvimento do sistema em relação aos NFRs que ele precisa atender.

As decisões tomadas durante o projeto podem afetar de forma positiva ou negativa os RNFs.

Essas interdependências servem para explicar o motivo pelo qual o sistema atende ou não a determinado RNF.

Comparação entre as abordagens orientadas a processo e a produto: não existe uma abordagem melhor que a outra; elas são complementares e devem ser usadas para obter sistemas que, de fato, atendam aos requisitos não funcionais dos stakeholders. Durante o estágio inicial de análise de requisitos, é recomendável usar abordagens de processo. As abordagens orientadas a produto são indicadas quando os requisitos estão bem definidos e podem ser especificados em termos de funcionalidades e fatores qualitativos mensuráveis.

Principais características

Confiabilidade: valia quanto um programa executa as funções pretendidas com a precisão exigida.

Eficiência: verifica a quantidade de recursos computacionais exigida para que um programa execute suas funções.

Flexibilidade: esforço necessário para modificar um programa.

Integridade: identifica o controle de acesso ao software ou aos dados por pessoas não autorizadas.

Interoperabilidade: envolve o quantitativo de esforço necessário para se acoplar um programa a um outro.

Manutenibilidade: relativa ao esforço necessário para localizar e eliminar erros em um programa.

Portabilidade: esforço necessário para transferir um programa de uma plataforma de hardware ou software para outra.

Reusabilidade: identifica a reutilização de um programa (ou parte dele) em outros programas.

Testabilidade: engloba o esforço necessário para testar um programa.

Usabilidade: verifica o esforço necessário para aprender, inserir dados e interpretar a saída de um programa.

Problemas comum nos requisitos

Nem sempre são óbvios.

São originados de várias fontes (conflitos de interesse).

Nem sempre retratam um problema que é possível de ser expresso por palavras.

Sempre mudam.

Os usuários nem sempre sabem o que desejam.

Os usuários têm uma tendência de privilegiar a sua área ou o seu ponto de vista.

Os analistas pensam que entendem os problemas melhor do que os próprios usuários.

Classes de requisitos

Essenciais:

são os requisitos sem os quais o sistema não entra em funcionamento. Requisitos essenciais são requisitos imprescindíveis, que têm que ser implementados impreterivelmente.

Importante:

é o requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema poderá ser implantado e usado mesmo assim.

Desejável:

é o requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis são requisitos que podem ser deixados para versões posteriores do sistema caso não haja tempo hábil para implementá-los na versão que está sendo especificada.

Requisitos de domínio

Também chamados de restrição, os requisitos de domínio são derivados do domínio de aplicação e seus processos, podendo ser novos requisitos funcionais em si, restringir os requisitos funcionais existentes, ou estabelecer como realizar cálculos e processamentos específicos.

Os requisitos de domínio estão relacionados ao comportamento próprio do sistema numa determinada aplicação ou no contexto "funcionando" para uma empresa. Esses requisitos restringem o próprio sistema; por exemplo, o sistema deverá ser implementado utilizando os serviços da web. Além disso, esses requisitos não são implementados, mas são cumpridos, pois limitam o espaço da solução disponível durante o processo de desenvolvimento.

Sem uma compreensão satisfatória desses requisitos, pode ser impossível fazer o sistema operar de forma satisfatória (PRESSMAN, 2006), concluindo-se, então, que se não forem satisfeitos, pode ser impossível fazer o sistema operar adequadamente. Sommerville (2007) afirma que eles descrevem restrições sobre os serviços ou funções oferecidas pelo sistema. Ainda, limitam as opções para criar uma solução para o problema (PFLEEGER, 2004).

[RN1]: os campos referentes ao orçamento do projeto vinculado só estarão ativos se o tipo de projeto for vinculado;

[RN2]: o campo valor total orçado para o projeto é calculado somando-se os valores definidos para todas as rubricas incluídas no orçamento do projeto, seja ele vinculado ou não vinculado;

[RN3]: a soma dos percentuais a serem distribuídos entre os fundos incluídos no plano de aplicação deve ser entre 0 e 100%.

Esses requisitos são expressos com o uso de uma linguagem específica do domínio da aplicação e, geralmente, de difícil compreensão para os engenheiros de software. Os especialistas do domínio podem, por julgarem óbvio, deixar de fornecer informações importantes e, como resultado, o requisito pode não ser implementado de forma satisfatória (SOMMERVILLE, 2008), ou seja, em um sistema de Departamento de Pessoal, por exemplo, são utilizados termos e regras específicos da área, e muitas vezes, o analista de requisitos não os conhece por não trabalhar em tal área e não ter a mesma experiência que seu cliente tem no ramo.

Simplificando, trata-se de requisitos que são do conhecimento do processo, do departamento e/ou da empresa cliente. Exemplificando: em um sistema de gestão de operadora de plano de saúde, os requisitos de domínio são conhecimentos específicos desta área de atuação, os quais apenas as pessoas que estão na empresa há anos possuem e podem detalhar de forma precisa ao analista de requisitos. Por isso, é de extrema importância que o analista de requisitos faça as perguntas certas, e que se atente aos mínimos detalhes.

Documentação de requisitos

Um documento de requisitos, segundo a norma IEEE, deverá conter declarações não ambíguas, e ser verificável, consistente, modificável, rastreável e usável durante todas as fases do ciclo de vida do requisito (IEEE; ANSI, 1996).

Todos os requisitos de um sistema devem ser capturados, modelados e documentados.

Podemos modelar e documentar os requisitos em diversas formas, como, por exemplo, casos de uso, diagramas DFD, diagrama SADT, rede de Petri etc.

Requisitos na forma de casos de uso são utilizados quando existe interação (diálogo) entre os atores e o sistema. Eles descrevem o objetivo do ator ao interagir com o sistema.

Requisitos na forma declarativa são utilizados quando é necessário descrever o que o sistema deve fazer em situações em que não existe iteração (ou em que a iteração é mínima) do ator com os sistemas.

Introdução

Objetivo

Escopo

Identificar pelo nome o produto de software a ser produzido (por exemplo, Gerenciador Eletrônico de Documentos – GED);

Explicar o que o produto vai e, se necessário, não vai fazer;

Descrever a aplicação de software que está sendo especificada, incluindo seus benefícios, objetivos e metas;

Ser consistente com outras especificações de alto nível do sistema, se elas existirem.

Definições, acrônimos e abreviações

Esta subseção deve conter todas as definições de termos, acrônimos e abreviações necessárias para corretamente entender a especificação. Essas informações podem ser apresentadas em apêndice ou em referências a outros documentos.

Referências

Esta subseção deve:

conter uma lista completa de todos os documentos referenciados na especificação;

identificar cada documento adequadamente com título, autores, data, editor etc.;

especificar as fontes de onde as referências foram obtidas.

Visão geral

Esta subseção deve:

descrever resumidamente o conteúdo do restante da especificação;

explicar como a especificação está organizada.

Descrição geral

Requisitos funcionais

Descrever as funcionalidades do software: produzir uma lista de todos os requisitos funcionais e classificá-los como obrigatórios, desejáveis ou opcionais.

Requisitos não funcionais

Descrever os requisitos não funcionais do software: produzir uma lista de todos os requisitos não funcionais e classificá-los segundo a taxonomia dos requisitos não funcionais.

Requisitos de interface

Definir como o software interage com as pessoas, com o hardware do sistema, com outros sistemas e com outros produtos. Detalhar os aspectos das interfaces do produto (normalmente, é feito um esboço das interfaces, levantado através de um protótipo ou de estudos em papel; também são detalhadas as interfaces com outros sistemas e componentes de sistemas). É obrigatório o desenho das telas referentes às principais funcionalidades do produto.

Atributos de qualidade

Descrever os requisitos de desempenho (velocidade de processamento, tempo de resposta etc.) e outros aspectos considerados necessários para que o produto atinja a qualidade desejada (por exemplo, portabilidade, manutenibilidade, confiabilidade etc.). Finalmente, classificar e rever os requisitos, estabelecendo prioridades (obrigatório, desejável ou opcional).

Características dos usuários

Descrever as características gerais dos usuários do produto, incluindo o nível educacional, a experiência e os conhecimentos técnicos.

Restrições

Enumerar as restrições impostas pela aplicação, tais como padrões, linguagem de implementação, ambientes operacionais e limites de recursos.

Suposições e dependências

Listar todos os fatores que afetam os requisitos da especificação. Esses fatores não são restrições ao projeto do sistema, mas sim, mudanças que podem afetar os requisitos. Por exemplo, uma suposição pode ser de que a aplicação será instalada em um sistema operacional específico; se esse sistema operacional não estiver disponível, isso poderá afetar os requisitos.

Anexo

Citar todos os recursos e técnicas utilizadas para a extração de requisitos, assim como as questões feitas, os nomes das pessoas, as empresas, os telefones e as datas de contato.

Seite 4

TÉCNICAS DE LEVANTAMENTO DE REQUISITOS

Técnicas de Levantamento de RequisitosTécnicas de Levantamento de Requisitos

Um requisito no âmbito da engenharia consiste na definição documentada de uma propriedade ou comportamento que um produto ou serviço particular deve atender (SERRA, 2019).

Na abordagem clássica de engenharia, conjuntos de requisitos são tipicamente utilizados como informações fundamentais para a fase de projeto de um produto ou serviço, especificando as propriedades e funções necessárias (ou desejáveis) a serem consideradas no desenvolvimento do projeto em questão.

O conceito de requisito é também utilizado formalmente na ciência de computação, engenharia de software e engenharia de sistemas.

Ele refere-se à definição de uma característica, atributo, habilidade ou qualidade que um sistema (ou qualquer um de seus módulos e sub-rotinas) deve necessariamente prover para ser útil a seus usuários.

Um requisito no âmbito da engenharia consiste na definição documentada de uma propriedade ou comportamento que um produto ou serviço particular deve atender (SERRA, 2019).

O conceito de requisito é também utilizado formalmente na ciência de computação, engenharia de software e engenharia de sistemas.

Ao final deste conteúdo, você será capaz de:

Diferenciar as técnicas de levantamento de requisitos.

Utilizar técnicas de levantamento de requisitos adequadas ao contexto de desenvolvimento de software.

Elaborar especificações de requisitos para o desenvolvimento de software

Uma palavra, muitos significados

O termo “requisito” é comumente considerado como sinônimo de “documentação com as especificações de requisitos” pelos profissionais de software, que não percebem o desenvolvimento dos requisitos como parte integrante da produção de software.

É evidente que a documentação é fruto da necessidade do registro dos resultados do trabalho intelectual, para que a informação não se perca e possa ser confirmada e compartilhada posteriormente. Contudo, a definição de requisitos deve ser mais abrangente do que apenas a documentação com as especificações de requisitos.

O tratamento do trabalho de requisitos como sinônimo de documentação falha quando se avalia com maior profundidade a definição de qualidade, como presente em uma variedade de modelos de referência, como a ISO 9000, o PMBOK® Guide e o BABOK®. Qualidade é aderência aos requisitos (CROSBY, 1979).

Desse modo, conclui-se que o produto é de qualidade se suas características estão compatíveis com sua especificação; mesmo que não atenda à necessidade que se propõe. Assim, o produto não pode ser rejeitado ou corrigido, gerando custos adicionais para atender a necessidade que o produto propôs.

Então, essa interpretação restrita entra em colapso quando a própria Engenharia de Requisitos e seus produtos devem ser avaliados quanto à qualidade. Portanto, o objetivo desta unidade de ensino é apresentar essa definição de requisito mais ampla e como ela deve ser usada na Engenharia de Requisitos.

Necessidade

De acordo com Juran (1988): “qualidade é a adequação ao uso”, sendo assim, a adequação ao uso é cumprir seu propósito, cumprindo as necessidades.

Muitas pessoas possuem o sonho de adquirir a casa própria e mesmo que ainda não concreta, a necessidade de segurança existe. Assim, o desejo é útil para ter as necessidades estabelecidas. Isso ajuda a entender que o requisito não se restringe à documentação com sua especificação, mas sim refere-se às diferentes necessidades que devem ser atendidas.

Propriedade

Uma vez que uma pessoa conclua seu desejo de aquisição de uma casa, constata-se que essa possui uma área, com uma certa quantidade de quartos, cozinha, jardim, garagem etc.

Especificação

Seja o requisito uma necessidade a ser satisfeita ou uma propriedade de um produto existente em ambos os casos, o requisito pode ter suas capacidades especificadas em um documento. Como no exemplo da casa, uma planta de um imóvel pode representar tanto um imóvel que se deseja construir como um imóvel já existente.

Falhas

As falhas em requisitos estão entre as principais razões para o fracasso de um software. Entre as principais razões destacam-se os requisitos mal organizados, requisitos mal expressos, requisitos desnecessários para os clientes e a dificuldade para lidar com requisitos frequentemente mutáveis.

A Figura mostra, de maneira esquemática, as mudanças de entendimento sobre os requisitos durante a especificação de um software, desde o cliente explicando o que ele deseja em cada uma das etapas até o momento da entrega do sistema.

Entre os problemas típicos encontrados com a especificação dos requisitos temos:

Falta de conhecimento sobre o domínio;

Comunicação do Usuário com o Analista;

Gestão de Mudanças e Evolução dos Requisitos;

Todo sistema contém erros ("infelizmente"). Esses erros são menos dispendiosos para corrigir, se forem encontrados durante a fase de requisitos. Quanto mais tempo eles existirem durante o desenvolvimento do sistema, mais caro torna-se a sua identificação e correção (SERRA, 2019).

Existe uma regra, do 1:10:100 conforme a Figura 2, que demonstra que quando um requisito é bem definido e especificado no início, seu investimento é de R$ 1 antes de começar o projeto, R$ 10 no meio, ou R$ 100 depois de concluído. O grande erro das pessoas é julgar que podem acertar o projeto no meio ou no fim sem nenhum prejuízo.

Engenharia de requisitos

A engenharia de requisitos fornece um mecanismo adequado para entender o que o cliente deseja, analisar as necessidades, negociar uma solução adequada, validar a especificação e administrar os requisitos à medida que eles são transformados em um sistema em operação.

A engenharia de requisitos pode ser dividida em alguns passos:

Conteúdo

A engenharia de requisitos pode ser dividida em alguns passos::

concepção ou estudo de viabilidade do sistema;

levantamento dos requisitos;

técnicas de extração de requisitos;

especificação dos requisitos;

validação dos requisitos;

gestão de requisitos.

Concepção/Estudo de viabilidade

O estudo de viabilidade é um estudo breve, direcionado, que se destina a responder algumas perguntas:

O sistema contribui para os objetivos gerais da empresa?

O sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de custo e prazo?

O sistema pode ser integrado com outros sistemas já em operação?

Após responder essas questões, é necessário questionar as fontes de informação (gerentes do negócio, área de TI, usuários finais etc.). Para isso, são realizadas algumas perguntas, como:

Como a empresa se comportaria, se esse sistema não fosse implementado?

Quais são os problemas com os processos atuais e como um novo sistema ajudaria a diminuir esses problemas?

Que contribuição direta o sistema trará para os objetivos da empresa?

As informações podem ser transferidas para outros sistemas e também podem ser recebidas a partir deles?

O sistema requer tecnologia que não tenha sido utilizada anteriormente na empresa?

O que precisa e o que não precisa ser compatível com a empresa? Quem vai usar o sistema?

Levantamento dos requisitos

Após o estudos iniciais de viabilidade, o próximo passo é o levantamento dos requisitos. Nesta etapa, deve-se descobrir mais informações sobre o domínio da aplicação, que serviços o sistema deve oferecer, desempenho exigido, entre outros.

O levantamento e análise de requisitos pode envolver diferentes tipos de pessoas da empresa. O termo stakeholder (envolvidos ou interessados) é utilizado para qualquer pessoa que terá alguma influência direta ou indireta sobre os requisitos do sistema. Exemplo: usuários finais, área de TI, gerentes de negócio, entre outros.

Técnicas de extração de requisitos

As técnicas de levantamento de requisitos têm por objetivo superar as dificuldades relativas encontradas na fase de levantamento de requisitos. Todas as técnicas possuem um conceito próprio e suas respectivas vantagens e desvantagens, que podem ser utilizadas em conjunto pelos analistas.

Algumas técnicas de extração de...

requisitos:

Levantamento orientado a pontos de vista;

Etnografia;

Entrevistas;

Questionários;

Brainstorming;

JAD (Joint Application Development);

Prototipação.

Levantamento a pontos de vista

Em um sistema relativamente simples, existem muitos pontos de vista diferentes que devem ser considerados, por isso os stakeholders envolvidos deverão expor suas ideias e seus pontos de vista.

Desse modo, os diferentes pontos de vista de um problema geram diferentes visões, assim dentro da engenharia de requisitos, esses diferentes pontos de vista são reconhecidos e utilizados para estruturar e organizar o processo de levantamento de dados e requisitos.

A análise se divide em etapas, a primeira etapa é identificar os possíveis pontos de vista, onde os analistas se reúnem com os stakeholders e utilizam o brainstorming para identificar os serviços em potencial e as entidades que interagem com o sistema. A segunda etapa consiste na estruturação dos pontos de vista, relacionando-os seguindo uma hierarquia. A terceira etapa é a documentação, seguida pelo mapeamento de sistema conforme ponto de vista, conforme exemplificado na figura a seguir, que mostra as etapas da técnica de levantamento orientado a ponto de vista.

Etnografia

A etnografia é uma observação participante, que investiga e caracteriza por um período de interações sociais intensas entre o investigador e os sujeitos, no meio destes, durante o qual os dados são recolhidos de forma sistemática (BOGDAN; TAYLOR, 1975).

Pode ser usada para compreender os requisitos sociais e organizacionais, compreendendo a política de trabalho para se familiarizar com o sistema e sua história.

Na etnografia o analista se insere no campo de trabalho em que o sistema será utilizado, segundo Michael Genzuk (1993), é um método de olhar de muito perto, que se baseia em experiência pessoal e em participação, que envolve as seguintes formas de recolher dados:

Entrevista - é necessário identificar as áreas de usuário a serem observadas; obter a aprovação das gerências apropriadas para executar as observações; obter os nomes e funções das pessoas-chave que estão envolvidas no estudo de observação; e explicar a finalidade do estudo;

Observação - observar os agrupamentos organizacionais atuais; as facilidades manuais e automatizadas; coletar amostras de documentos e procedimentos escritos que são usados em cada processo específico que está sendo observado; e acumular informações estatísticas a respeito das tarefas, como: frequência que ocorrem, estimativas de volumes, tempo de duração para cada pessoa que está sendo observada.

Entrevista

A entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção de dados. É importante que o entrevistador dê margem ao entrevistado para expor as suas ideias. Basicamente existem dois tipos de entrevistas.

Há as entrevistas fechadas, em que perguntas são definidas previamente e o stakeholder irá respondê-las da forma que foi concebida; e as entrevistas abertas, em que não há um roteiro predefinido de questões, o engenheiro de requisitos explora diversos assuntos com a finalidade de obter uma maior compreensão sobre as necessidades do stakeholder (SOMMERVILLE, 2007).

Para desenvolver entrevistas bem sucedidas existem algumas diretrizes a seguir, por exemplo: desenvolver um plano geral de entrevistas, certificar-se da autorização para falar com os usuários, planejar a entrevista para fazer uso eficiente do tempo, utilizar ferramentas automatizadas que sejam adequadas, tentar descobrir em que informação o usuário está mais interessado e usar um estilo adequado ao entrevistar.

Outros pontos a serem considerados são a atitude do analista em relação à entrevista e sua forma de conduzi-la, o que irá determinar seu fracasso ou sucesso. O modo como o analista fala não deve ser muito alto, nem muito baixo, tampouco indiretamente, não criticando a credibilidade do entrevistado. O analista deve ter em mente que o entrevistado é o perito no assunto e fornecerá as informações necessárias ao sistema.

As vantagens da utilização dessa técnica é que ela é mais flexível e tem o objetivo de adquirir informações de caráter subjetivo. Além disso, aproxima o engenheiro de requisitos do usuário do sistema, fazendo com que o usuário se sinta atuante do desenvolvimento do sistema. As desvantagens seriam o custo de tempo e esforço caso precise o engenheiro de requisitos entrevistar inúmeros usuários do sistema. Isso resultaria em uma maior dificuldade para tabular todos os dados obtidos (MARTINS, 2001).

A entrevista é uma série de encontros com os clientes ou usuários que explicam o seu trabalho, ambiente em que atuam, necessidades etc.

Uma entrevista requer desenvolvimento de habilidades sociais (saber ouvir, saber inferir etc.) por parte da equipe de desenvolvimento.

Questionário

Forma rápida de se obter dados de uma grande quantidade de usuários que podem estar em lugares geograficamente distintos.

Existem muitos tipos de questionários, por exemplo: múltipla escolha, lista de verificação e questões com espaços em branco. Seu uso é indicado quando vários grupos de usuários estão em diferentes locais do país, sendo assim o questionário deve ser elaborado de forma a minimizar o tempo gasto em sua resposta.

Na fase de preparação do questionário deve ser indicado o tipo de informação que se deseja obter. Assim que os requisitos forem definidos o analista deve elaborar o questionário com questões de forma simples, clara e concisa, considerando o tipo de informação que se deseja obter. É necessário deixar espaço suficiente para as repostas que forem descritivas e agrupar as questões de tópicos específicos em um conjunto com um título especial.

Todo questionário tem um enunciado explicativo enfatizando a importância da pesquisa, deve ser mantido um controle sobre a distribuição e identificação das pessoas que o recebem, identificação de como preencher e o tempo de retorno.

Após analisar as respostas dos participantes é feita uma compilação das informações fornecidas no questionário, documentando as principais descobertas e enviando uma cópia com estas informações para o participante como forma de agradecimento pelo tempo dedicado.

Tipos de dados que podem ser coletados

Os tipos de dados que podem ser coletados são:

Utilização do sistema atual;

Problemas e dificuldades que os usuários enfrentam em seu trabalho;

Expectativa dos usuários em relação ao novo sistema.

As questões são claras e objetivas.

Elaboração do questionário

Questões mais importantes devem vir primeiro.

Questões com conteúdo semelhante e relacionadas devem estar próximas.

Questões que podem gerar controvérsias devem ser deixadas para depois.

Modelo de questionário do RUP (Solicitação dos Principais Envolvidos).

Brainstorming

A ferramenta mais antiga e utilizada para promover o pensamento divergente é conhecida como brainstorming ou Tempestade de ideias (COSTA et al., 2011; MELO; ABELHEIRA, 2015).

Caracterizado como uma técnica para geração de ideias o brainstorming consiste em um processo de geração de muitas e variadas ideias, sendo um aspecto importante da criatividade individual e coletiva.

Para conduzir uma sessão de brainstorming é necessária uma seleção de participantes, explicação das técnicas e regras a serem seguidas e a produção de uma tempestade de ideias, ou seja, os participantes devem produzir uma boa quantidade de ideias, levando a soluções criativas para os problemas, enriquecendo e combinando as ideias apresentadas entre si.

Seite 5

ESPECIFICAÇÃO DE REQUISITOS ÁGEIS

Especificação de Requisitos Ágeis

Os métodos ágeis são eficientes para alguns tipos de sistemas, como em desenvolvimento de produtos para venda em pequeno e médio porte ou também em desenvolvimento de sistemas que o cliente estará envolvido no processo de desenvolvimento e que não há muitas regras que afetam o software.

Aplicações web, por exemplo, aceitam bem a metodologia ágil, pois normalmente os seus requisitos mudam constantemente. A abordagem ágil pura em sistemas críticos também não é vista com bons olhos, pois estes sistemas necessitam de toda uma análise de confiança e segurança, fazendo com que sejam feitas mudanças nos métodos antes de serem usados.

De acordo com o Chaos Manifesto (2012, Standish Group) foi apontado que 49% de sucesso de projetos era em abordagens ágeis, enquanto abordagens dirigidas a planos foram de 14%.

Entretanto, ágil não significa de sucesso. Como no momento da criação, o foco era sistemas de pequeno e médio porte, a aplicação dos métodos em sistemas de grande porte é difícil, onde se faz necessário documentações e projeto já adiantados. Quanto a equipes, quando existem várias destas trabalhando, também fica mais difícil integrá-las.

Também é necessário ressaltar que quando a metodologia ágil é usada sem engajamento da equipe, é grande a possibilidade de fracasso do projeto.

Texto

Antes de iniciarmos o conteúdo desta unidade, te convido a ler o texto 'As Origens do Ágil', páginas 26 a 48: https://plataforma.bvirtual.com.br/Leitor/Publicacao/160051/epub/0

CRUZ, Fábio. Scrum e Agile em Projetos (2a. edição): guia completo. Brasport, 2018.

Atenção: lembre-se de logar na sua conta do Ulife para acessar o texto indicado.

É importante ressaltar que XP e Scrum são abordagens ágeis bastante utilizadas nas empresas, mas não são as únicas. Assim, é adequado conhecer o que cada alternativa oferece dentro da filosofia ágil.

Ao final deste conteúdo, você será capaz de:

Reconhecer diferentes formas de desenvolver software de acordo com a filosofia ágil.

Diferenciar as abordagens de desenvolvimento ágil de software XP e Scrum.

Elaborar requisitos de software em contextos ágeis.

SCRUM

Origem do termo

Scrum é o nome de uma das jogadas do Rugby, tendo como principal característica a formação vista ao lado. Disputa-se a reposição de bola e é necessária a participação de todos os jogadores do time atuando em conjunto no mesmo objetivo, sendo que se um deles falhar, todos falham. Este trabalho em equipe é bem caracterizado no framework do Scrum, por isso o seu nome.

Definição do Scrum

O Scrum, processo definido por Schwaber e Sutherland (2001), foi criado para o gerenciamento do desenvolvimento de software em ambientes cujos requisitos são voláteis. É uma abordagem empírica baseada na flexibilidade, adaptabilidade e produtividade.

O Scrum deixa a cargo dos desenvolvedores a escolha das técnicas de desenvolvimento específicas para o projeto e envolve atividades frequentes de gestão, visando identificar quaisquer deficiências e impedimentos no processo de desenvolvimento (BONATO, 2004, p. 78).

Ele não chega a ser um método, pois especifica apenas o que deve ser feito, mas não o como deve ser feito.

Exemplo

Por exemplo: é necessário que haja um momento de planejamento do Time Scrum para o próximo ciclo de desenvolvimento, porém, o Guia não descreve como esse momento é realizado. Fala sobre os artefatos que devem existir, no entanto, não exaustivamente. O formato dos mesmos também não é apresentado. O Scrum sempre irá requerer adaptações para os contextos específicos das organizações.

Teoria do Scrum

Scrum é fundamentado nas teorias empíricas de controle de processo, ou empirismo. O empirismo afirma que o conhecimento vem da experiência e de tomada de decisões baseadas no que é conhecido. O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos.

Três pilares apoiam a implementação de controle de processo empírico:

FIGURA 1 | PILARES SCRUM

Acompanhe, a seguir, cada um desses pilares.

Transparência

O processo utilizado pelo Time Scrum, suas atividades e expectativas devem ter visibilidade para os interessados nos resultados do Time. Nada deve ser varrido para debaixo do tapete. Além disso, é necessário que os envolvidos utilizem uma linguagem comum compreendida por todos para que a comunicação flua.

Normalmente, essa transparência é implementada com o Quadro de Tarefas no qual o time dá visibilidade ao fluxo de trabalho e aos itens de valor que estão sendo desenvolvidos.

Times mais maduros são mais transparentes. O relacionamento e a confiança entre eles e os demais stakeholders exerce forte influência na transparência. Se há uma relação de desconfiança ou imaturidade, teremos muito trabalho “escondido” e pouca visibilidade.

Além disso, a transparência está relacionada aos papéis que as pessoas desempenham durante o desenvolvimento do produto, resultados alcançados, expectativas, colaboração etc.

Exemplo

Uma linguagem comum referindo-se ao processo deve ser compartilhada por todos os participantes; e,

Uma definição comum de “Pronto” deve ser compartilhada por aqueles que realizam o trabalho e por aqueles que aceitam o resultado do trabalho.

Inspeção

Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção a detectar variações. Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas. As inspeções são mais benéficas quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar.

Adaptação

Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos limites aceitáveis, e que o produto resultado será́ inaceitável, o processo ou o material sendo produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível para minimizar mais desvios.

O Scrum prescreve quatro Eventos formais, contidos dentro dos limites da Sprint, para inspeção e adaptação:

reunião de planejamento da Sprint;

reunião diária;

reunião de revisão da Sprint;

retrospectiva da Sprint.

Valores do Scrum

São cinco valores do Scrum:

Coragem

Foco

Comprometimento

Respeito

Abertura

O Time Scrum

Recurso lista interativa:

O Time Scrum é composto pelo:

Times Scrum são:

Conteúdo

O Time Scrum é composto pelo::

Product Owner;

Time de Desenvolvimento; e,

Scrum Master.

Scrum Master

O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado, ou seja, é o facilitador do time. Ele busca insistentemente construir o melhor time do mundo e por isso trabalha para manter o Scrum funcionando. É um líder servidor que auxilia o Product Owner, Time de Desenvolvimento e demais stakeholders a compreender e praticar o Scrum, como também ajudar aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum. É ele que ajuda o Time Scrum a remover impedimentos e, se necessário, promover as mudanças organizacionais para que a empresa seja mais eficaz e eficiente.

Product Owner

É ele quem dá a direção do produto. Ele é responsável por verificar os problemas pela perspectiva do cliente e em conjunto com o Time de Desenvolvimento elaborar uma solução que os resolva e ainda traga resultados de negócio para a organização. Ele é o responsável por priorizar quais são as próximas fatias do produto a serem desenvolvidas e verificar os impactos causados pelas entregas por meio de métricas de eficácia. É uma pessoa de visão sistêmica que entende sobre estratégias de negócio, produto, clientes, concorrentes, resultados etc.

Time de Desenvolvimento

O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos.

Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e eficácia do Time de Desenvolvimento como um todo.

Características do Time de Desenvolvimento

Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis. Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.

Tamanho do Time de Desenvolvimento

O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho dentro dos limites da Sprint. Menos de três integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade. Times de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando um Time de Desenvolvimento incapaz de entregar um incremento potencialmente utilizável.

Usuários, clientes, gestores, consumidores finais e demais stakeholders

Esses papéis NÃO estão escritos no Guia do Scrum, mas sabemos que eles têm influência sobre o Time Scrum. Essas pessoas possuem necessidades que o nosso produto deve resolver. São elas quem consomem aquilo que o Time entrega. O valor da entrega depende da percepção que elas têm sobre o produto. Em breve, veremos que eles participam de alguns eventos.

O Ciclo Scrum

A imagem, a seguir, explica o Ciclo de Desenvolvimento do Scrum.

FIGURA 2 | CICLO DE VIDA SCRUM

Agora, veremos a descrição dessas etapas. Acompanhe!

Planejamento da Sprint

É o momento em que o Product Owner discute com o Time de Desenvolvimento quais itens do backlog serão desenvolvidos no próximo ciclo de construção do produto. O Scrum Master facilita a reunião garantindo que todos mantenham o foco e que os objetivos dela sejam alcançados.

Backlog do produto

O principal artefato de entrada é o Product Backlog. Ele é o conjunto de todas as necessidades dos clientes e do negócio que serão resolvidos pelo produto. Ele é mantido valorado e priorizado pelo Product Owner.

Os itens não possuem o mesmo nível de detalhamento. Aqueles que estão no topo do backlog (mais prioritários) possuem mais informações sobre o que faremos, qual o propósito de fazermos e para quem entregaremos. Quanto maior a prioridade, maior o detalhamento.

Objetivo da Sprint

Uma das primeiras coisas que o Time Scrum deve fazer no planejamento é definir qual o Objetivo da Sprint. Ele serve como um guia para a escolha dos itens.

Exemplo

Exemplos de objetivos:

disponibilizar os produtos de Dia das Mães nas lojas piloto de três localidades: Manaus, Fortaleza, Goiânia;

disponibilizar a compra rápida no site;

lançar o seguro de vida nas cidades de São Paulo, Curitiba e Rio de Janeiro.

Perceba que agora está claro...

onde queremos chegar no final da Sprint. Imagine que você está no time que vai disponibilizar produtos de Dia das Mães. Faria algum sentido construir um item de backlog relacionado ao Natal? Ou fazer algo para ser avaliado em Bauru?

Um ponto de atenção! No Guia do Scrum, o termo Sprint Goal foi traduzido para Meta da Sprint. Não se curte muito utilizar essa palavra nesse contexto, pois as pessoas a associam a fazer todos os itens selecionados no Sprint Backlog. Com isso, perdemos o propósito principal e podemos acabar selecionando itens de forma descoordenada da estratégia do negócio.

Backlog da Sprint

Uma vez definido o Objetivo da Sprint, o Time de Desenvolvimento, em conjunto com o Product Owner, define quais itens serão construídos na Sprint. É importante que a capacidade do time seja respeitada e o Scrum Master esteja lá para garantir isso. É comum que times Scrum utilizem o Planning Poker para definir essa capacidade.

O Time de Desenvolvimento pode detalhar ainda mais o item do backlog e para isso irá “quebrá-lo” em tarefas técnicas necessárias para transformá-lo em incremento do produto. O Sprint Backlog é o conjunto de itens do Backlog do Produto selecionados para a Sprint mais as tarefas técnicas.

Sprint

É o evento principal, ou seja, o coração do Scrum, e todo trabalho acontece durante ela. Seu início acontece quando começamos o Planejamento da Sprint e termina no final da Retrospectiva. Ela é um evento de período fixo (time-box).

Uma analogia para facilitar o...

entendimento de time-box é como se colocássemos o tempo dentro de uma caixa de aço que não pode se expandir. O tempo é como se fosse um líquido que enche a caixa. Quando lotar a caixa, acabou o tempo. Não há como colocar mais nada nela. Não tem aquele: “me dá mais uma semaninha que eu termino”.

Durante a Sprint, os itens do Sprint Backlog são construídos e transformados em incremento de produto potencialmente entregável.

Incremento do produto potencialmente entregável

Nome longo e estranho. Vamos explicar por partes. Incremento do produto é a aplicação do conceito de desenvolvimento iterativo e incremental adotado pelos Métodos Ágeis. Ao invés de ficarmos meses ou anos desenvolvendo um produto para entregarmos tudo ao final do projeto, no Scrum o produto é construído em várias iterações (i, i+1, i+2…). A cada iteração, incrementamos e aperfeiçoamos o produto.

Exemplo

Alguns exemplos de incremento:

no desenvolvimento de software, o incremento são as funcionalidades do software (features);

para a indústria de cosméticos, os incrementos podem ser o conjunto de produtos que serão lançados em um pacote. Por exemplo, no Dia das Mães, os incrementos poderiam ser: batom, perfume, óleo para o corpo. Cada um entregue em 1 ciclo e já pode ser testado por alguns consumidores finais antes de começar a promoção;

no marketing, os formatos de campanha de um produto: campanha em redes sociais, e-mail marketing, marketing fone, promotor etc.;

para advogados, a construção de peças jurídicas;

engenharia de produção, o incremento dos módulos de operação;

entre outros.

Potencialmente entregável porque o incremento tem que estar em um estado que possa ser utilizado pelo consumidor. Não pode ser aquele: está pronto, só falta testar! Também não é um protótipo que será descartado. Pode ser algo ainda incompleto, mas É UM PRODUTO / SERVIÇO consumível.

A entrega para o consumo é uma decisão de negócio e, portanto, depende da decisão do Product Owner. Isso acontece porque o Time pode entregar algo que ainda não é estrategicamente interessante lançar no mercado.

Exemplo

Por exemplo, digamos que o Time está trabalhando em outubro para o site de promoção de Natal. Ele pode e deve chamar os clientes para experimentar o novo site e coletar feedback durante as iterações, mas não seria interessante lançar esse site antes da metade de novembro.

Definição de Pronto

Para saber se o incremento está pronto para ser entregue para o consumidor, utilizamos a Definição de Pronto. São todas as restrições que o produto deve cumprir antes de ser entregue. Uma espécie de lista de verificação (checklist).

Exemplo

Exemplo de Definição de Pronto no Desenvolvimento de Software: código no repositório; passou em todos os testes no servidor de integração contínua; pacotes gerados etc.

Exemplo na engenharia de produção: robô instalado; manual de operação atualizado; regras de segurança afixadas em local visível etc.

Se o item não cumprir todas as exigências da Definição de Pronto, ele não está pronto e não pode ser entregue. No Scrum, não existe ½ pronto ou 99,99% pronto.

Duração da Sprint

A duração é fixa e pode ser de uma até no máximo quatro semanas com preferência o menor tempo possível. Esse período NÃO fica variando. Isso significa que caso o Time Scrum decida que a Sprint terá a duração de duas semanas, todas as Sprints terão a duração de duas semanas.

Posso reduzir o tamanho da Sprint?

Sim. Todavia, deve ser algo em que todos estão de acordo em fazer e tem que ser motivado por algum fato importante.

Exemplo

Por exemplo, o Time Scrum automatizou uma parte do processo e acredita que consegue fazer entregas de valor semanalmente. A partir de agora, todas as Sprints serão de uma semana.

Posso aumentar o tamanho da Sprint?

Muito cuidado ao fazer isso. O Time pode estar apenas escondendo um problema, ao invés de resolvê-lo na causa raiz.

Exemplo

Por exemplo: o time aumenta a Sprint em uma semana porque a qualidade do produto está baixa e as pessoas de qualidade têm apenas algumas horas para verificar o produto. Agora, serão duas semanas de desenvolvimento mais uma semana de teste.

No início, todos acham que isso resolve o problema, mas não é verdade. Em breve esse time irá aumentar para quatro semanas, pois, na prática, o tempo de desenvolvimento também aumentará. A raiz do problema que deveria ser tratada é a baixa qualidade no desenvolvimento.

As consequências de aumentar o tamanho da Sprint:

Uma conta simples para vermos o quão ruim é uma Sprint grande demais:

Perceba que quanto maior a Sprint, menos experimentos teremos e, com isso, ficamos mais suscetíveis a sofrer as consequências listadas anteriormente.

Reunião Diária

Logo após o Time Scrum definir o Sprint Backlog, começa o trabalho de transformar os itens selecionados em incrementos do produto. Durante esse período, diariamente, o Time de Desenvolvimento se reúne em frente ao Quadro de Tarefas para fazer a Reunião Diária. Essa é uma reunião do Time de Desenvolvimento para o Time de Desenvolvimento. O Scrum Master facilita, se necessário, e a presença do Product Owner não é obrigatória. Pessoas externas (gestores, stakeholders, curiosos) só participam se o Time de Desenvolvimento concordar e ficam em silêncio durante todo o evento. Queremos criar um ambiente seguro de colaboração e não um momento de status report e justificativas.

Esse evento tem a duração máxima de 15 minutos e o objetivo é definir o que o Time de Desenvolvimento fará para dar mais alguns passos rumos ao Objetivo da Sprint naquele dia. É um momento para o Time fazer a inspeção (vamos atingir o Objetivo da Sprint?) e adaptação (o que faremos para corrigir o curso e atingir o Objetivo da Sprint?).

Para auxiliar esse propósito, existem três perguntas sugeridas no Guia do Scrum, mas elas não são obrigatórias.

O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir o objetivo da Sprint?

O que eu farei hoje para ajudar o Time de Desenvolvimento a atingir o objetivo da Sprint?

Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento de atingir o objetivo da Sprint?

Quadro de Tarefas

É uma ferramenta de transparência do Time Scrum. Ele contém todo o trabalho que o time deve fazer durante a Sprint, inclusive atividades que não estão relacionadas ao desenvolvimento do produto (participações em comitês, apoio a outros times, manutenção em outros produtos, reuniões etc.).

O quadro pode começar no formato mais simples com três estágios de desenvolvimento: coisas a fazer, o que o Time de Desenvolvimento está fazendo e o que ele já fez. Com o passar do tempo, o Quadro poderá refletir o fluxo de trabalho mais completo.

Gráficos de Acompanhamento

O Time Scrum também pode manter gráficos de acompanhamento para visualizar mais facilmente a evolução da Sprint ou a construção do produto inteiro. Os gráficos mais comuns de acompanhamento são o Burn Down Chart, Burn Up Chart, Gráfico de Valor e o Cumulative Flow Diagram (CFD).

Uma pergunta comum: quem é o responsável por atualizar o gráfico?

Se o gráfico é relevante para o Time de Desenvolvimento, ele deve mantê-lo atualizado. Se é um gráfico utilizado para alimentar informações para outros stakeholders, essa atualização poderá ser feita pelo Scrum Master, Product Owner ou o próprio Time de Desenvolvimento.

Revisão da Sprint

Ao final da Sprint, o incremento do produto é apresentado para consumidores, usuários, clientes, gestores e demais stakeholders. Todo o Time Scrum participa. O objetivo primário desse evento é obter feedback sobre o produto. O livro "The mom test", de Fitzpatrick (2013), tem excelentes dicas de como fazer perguntas para obter bons feedbacks.

Os feedbacks proporcionados pelos convidados...

podem se tornar novos itens do Backlog do Produto. Eles podem ser muito estratégicos e entrarem no topo do backlog. Caso contrário, eles podem entrar no meio ou no final do mesmo. Há também a possibilidade de descartar o feedback, caso ele seja irrelevante.

O correto nesse evento é que o consumidor utilize o produto. Não é uma reunião para apresentar slides ou incrementos que não atendem a Definição de Pronto.

Nessa reunião, podem ser apresentadas informações sobre o andamento do projeto, mas o foco sempre será o feedback sobre o uso do produto ou serviço.

Retrospectiva da Sprint

É o momento da melhoria contínua. Todo o Time Scrum participa: Product Owner, Scrum Master e todos os membros do Time de Desenvolvimento. O objetivo dela é melhorar a forma de trabalho de todo time.

É um ambiente seguro em que o Time Scrum discute sobre falhas e pontos fracos. Logo, não devemos ter pessoas externas. A única exceção é se o time inteiro concordar em convidar alguém de fora.

Refinamento do Backlog do Produto

Esse não é um evento oficial no Scrum, mas é uma boa prática. O refinamento pode ser feito a qualquer momento e podemos fazer reuniões para tal. O objetivo é manter o Backlog do Produto atualizado e priorizado com insumos de: novas ideias, resultados anteriores, clientes, gestores, alterações no mercado, mudanças nos competidores, inovações etc.

Também é interessante que o Time de Desenvolvimento participe do refinamento para estimar o esforço ou discutir a complexidade técnica dos itens mais prioritários. Todavia, não deve consumir mais do que 10% da capacidade do Time de Desenvolvimento durante a Sprint.

Caso o refinamento não seja feito antes, ele acontecerá no Planejamento da Sprint. Nesse caso, teremos uma reunião muito longa. O ideal é que no momento do planejamento, o Backlog do Produto já esteja atualizado, valorado, priorizado e, se possível, com o esforço estimado.

Definição de Preparado

Alguns times gostam de utilizar uma definição mínima que garante que o item foi refinado e pode ser discutido no Planejamento da Sprint. A Definição de Preparado também não é oficial do Scrum, mas ajuda o time a perder menos tempo e ter mais foco durante as discussões de planejamento.

Exemplo

Um exemplo poderia ser:

o item tem que estar escrito no formato de História de Usuário;

os critérios de aceitação estão definidos;

as métricas para medição de impacto do item foram selecionadas;

o valor de negócio do item foi definido;

consumidores do item foram convidados para Revisão da Sprint;

o esforço para construção do item foi estimado.

Aproveite a leitura do capítulo a seguir para obter uma visão detalhada de como as práticas de Scrum são adotadas no dia-a-dia de uma equipe de desenvolvimento de software.

Estudo Guiado

Leia do capítulo 3 do livro de Sbrocco e Macedo.

SBROCCO, José Henrique Teixeira de C.; MACEDO, Paulo Cesar D. Metodologias Ágeis - Engenharia de Software sob Medida. [Digite o Local da Editora]: Editora Saraiva, 2012. E-book. ISBN 9788536519418. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788536519418/. Acesso em: 07 set. 2022.

Extreme Programming é um processo de desenvolvimento ágil criado por Kent Beck no final da década de 90 durante o projeto C3 da Chrysler, “uma metodologia leve para times de tamanho pequeno a médio, que desenvolva software em face a requisitos vagos que se modificam rapidamente”.

Recurso lista interativa:

É baseada em 4 valores:

Alguns princípios:

E em 4 atividades básicas:

Conteúdo

É baseada em 4 valores::

comunicação;

simplicidade;

feedback;

coragem.

Cliente no Local

O cliente senta-se o tempo todo com a equipe, responde perguntas, define pequenas prioridades. O cliente deve ser alguém que realmente irá usar o sistema depois. Este papel existe na metodologia SAP; chama-se key user.

Jogo do Planejamento

Rapidamente estabelece o escopo (estórias de usuário) da próxima versão. Pessoal de negócio define o escopo, prioridades, composição das versões, datas das versões. Pessoal técnico decide sobre estimativas, consequências, processo, cronograma detalhado. A realidade é mais importante que o plano; este deve ser atualizado por ela.

Pequenas Versões

Colocar um sistema simples em produção rapidamente e entregar novas versões em um ciclo curto. Toda versão deve ser o menor possível e conter os mais valiosos requisitos de negócio.

Metáfora

Guia o desenvolvimento com uma estória curta sobre como o sistema funciona. Substitui o que outras metodologias chamam de arquitetura.

Definida logo no início do projeto.

Base: estórias listadas no backlog de produto inicial.

Age como um framework conceitual, identificando os objetos-chave e fornecendo uma visão de suas interfaces.

O fato de haver uma metáfora não implica que não haverá um diagrama de arquitetura.

A metáfora deve comunicar uma visão comum a todos os integrantes da equipe.

A metáfora fornece um sistema de nomes para os objetos: CarrinhoDeCompras, CaixaDeEntrega etc.

FIGURA 3 | EXEMPLO DE METÁFORA DE UM SISTEMA DE VENDAS ON-LINE

Descrição da Metáfora de um Sistema de Vendas On-line

Uma metáfora de mercearia seria uma candidata provável.

Um pedido é apenas como um carrinho de supermercado. Os clientes passeiam por sua loja on-line colocando itens nos carrinhos, tiram itens que não desejam e ao final levam os carrinhos para o caixa, onde as taxas, impostos, descontos e o preço total são calculados. Então, os itens selecionados são colocados em caixas e enviados de forma similar ao que os empacotadores de armazéns fazem ao colocar a mercadoria comprada em sacos e entregá-las ao cliente.

FIGURA 4 | DIAGRAMA DE ARQUITETURA EM MODELAGEM ÁGIL DO SISTEMA DE VENDAS ON-LINE

Projeto Simples

O que é?.

Passa em todos os testes.

Não tem lógica duplicada.

Tem o menor número possível de classes e métodos.

Define, claramente, a intenção dos programadores.

Testes

O programador escreve testes de unidade.

O cliente escreve testes de aceitação.

A confiança no sistema aumenta à medida que ele passa nos testes.

Refactoring – Reengenharia de Código

Primeiro o programador adiciona a nova funcionalidade; depois ele se pergunta se não há uma maneira mais simples de fazê-lo que ainda passe em todos os testes; isso é refactoring.

Programação por Pares

Dois desenvolvedores, um teclado, um mouse. O que está no teclado pensa na melhor maneira de implementar o método que está a sua frente. O outro pensa mais estrategicamente: como o todo vai funcionar; se há casos de teste que ainda não foram feitos; se há um jeito mais simples de fazer. Os pares devem ser trocados frequentemente; pode-se parear com um programador pela manhã e outro à tarde.

Propriedade Coletiva do Código

Todos são responsáveis pelo código como um todo.

Qualquer programador pode alterar qualquer parte do código.

Se alguém estragou alguma parte do código é responsável por corrigi-lo.

Integração Contínua

Código testado e integrado a cada poucas horas, um dia, no máximo.

Ter uma máquina dedicada a integração.

O par deve se sentar nesta máquina, integrar seu código e rodar todos os testes; os que não passarem o par corrige.

Semana de 40 horas

Não precisa ser 40 horas exatamente.

A ideia é que ninguém fica satisfeito, produtivo e criativo trabalhando 60 horas por semana durante muito tempo.

Horas extras não são a solução, mas o sintoma de um problema pior.

Padrões de Codificação

Facilita a comunicação.

Permite a troca constante dos pares.

Possibilita a propriedade coletiva do código.

São padrões de código, como o do Java, padrões de projeto OO como os do Gamma, padrões de projeto J2EE etc.

Chegamos ao fim deste conteúdo, confira a seguir, uma breve síntese com o que vimos até aqui.

Seite 6

COMPREENDER E PROJETAR BANCO DE DADOS

Tópico 01

Compreender e projetar banco de dados

Que mundo fascinante este no qual vivemos!

Em 2017, a "The Economist", em reportagem de capa, dizia Data is the new oil, ou seja, Dados são o novo petróleo. Estamos falando que é um bem tão valioso que precisa ser explorado, cuidado e tratado de maneira correta para que entregue o seu valor.

Saiba mais

DADO É O NOVO PETRÓLEO

Para embasar o que estamos falando, sugerimos você assistir ao vídeo a seguir para saber o que é esse novo petróleo.

https://www.youtube.com/watch?v=t4Bbp1PWZaE

O ser humano desde os primórdios da sua existência tem necessidade de deixar registrado como viveu na Terra. E as formas de registro são variadas. Na figura vemos as pinturas pré-históricas em cavernas (chamadas de arte rupestre) que ilustram o que os historiadores dizem ser cenas de caça, rituais, o cotidiano, expressando uma espécie de linguagem visual, conceitos, símbolos, valores e crenças - ou seja, o registro do povo da época:

A Figura anexa mostra uma pedra rochosa com alguns desenhos, que podem ser interpretados como corpos humanos e de animais.

Atualmente, há avanços tecnológicos em todos os aspectos no nosso dia a dia: telefones celulares, televisão via satélite, aeronaves avançadas, medicina moderna e computadores. Negócios de todos os tipos e tamanhos contam com computadores e os sistemas de informações dão suporte em um grau que teria sido inimaginável há apenas alguns anos.

Estamos falando que o ser humano da sociedade moderna está deixando de armazenar seus registros em meio físico, e cada vez mais digitaliza sua vida: fotos de viagem, conversas com amigos, documentos, tudo atualmente é transferido do mundo real para o virtual.

As empresas cada vez mais desenvolvem meios para esse novo mundo de possibilidades que é o universo digital e promovem cada vez mais o uso do meio digital.

Sabemos que a informação é um importante capital da empresa, pois o conhecimento que as corporações têm de seus clientes é muito valioso e é considerado o novo petróleo do mundo.

Por isso, para diminuir a redundância e o tempo, as organizações optam por salvar cada vez mais dados dos seus usuários de diferentes formas e utilizar este conhecimento de maneira oportuna.

O planeta gera informação a todo momento: a cada 60 segundos são gerados um grande volume de dados nas redes sociais, conforme mostra a figura a seguir, os dados são correspondentes a junho de 2020:

Devido a este grande volume de informação, foi assinada a Lei n. 13.709/2018 para proteger as informações pessoais de consumidores e usuários de serviços, conhecida como Lei Geral de Proteção de Dados (LGPD), a qual prevê que o usuário que sofrer vazamento dos seus dados possa ser indenizado e organizações poderão ser multadas por falha de segurança.

Devido ao volume de dados produzidos pela humanidade, vemos a importância e a relevância desses dados para as empresas continuarem sendo competitivas. Consequentemente, temos a necessidade da proteção destes dados que são produzidos, por isso, estudaremos sobre como guardar essas informações, para que seja gerado um valor para a empresa. Nesta unidade, buscaremos responder aos seguintes questionamentos:

Como encontrar os dados que atendam a necessidade da empresa?

Como documentar de forma eficiente os requisitos?

Como pensar em dados de forma organizada?

Como projetar os dados para que sejam armazenados de maneira eficiente?

Como podemos recuperar estes dados com eficácia?

Ao final deste conteúdo, você será capaz de:

Identificar as diferenças entre os conceitos de dado, informação e conhecimento.

Relacionar os componentes e objetivos de um sistema de banco de dados.

Explicar como os dados são modelados ao longo do processo de desenvolvimento de software.

Bons estudos!

Dados x Informação

Até aqui, falamos sobre dados e informação. Mas você sabe a diferença?

Há muita dúvida sobre o que é dado e o que é informação, pois ambos os conceitos estão relacionados. Dados são fatos brutos, que ainda não foram processados para revelar seu significado e devem ser formatados adequadamente para o armazenamento, o processamento e a apresentação.

Dados são fatos que podem...

ser gravados e que possuem um significado implícito (ELMASRI, 2011).

Já Informação é o resultado do processamento, manipulação e organização dos dados de tal forma que possa representar uma modificação (quantitativa ou qualitativa) no conhecimento do sistema (pessoa, animal, objeto ou máquina) que a recebe. Informação é o conjunto de dados associados a um contexto, de maneira que seja possível interpretá-la e analisá-la para produzir conhecimento e/o tomar decisões (PUGA; FRANÇA; GOYA, 2013).

O que é feito com a informação tratada gera CONHECIMENTO.

Conhecimento é quando temos familiaridade, consciência e compreensão destas informações e através deste conhecimento é possível gerar algo novo.

Um exemplo é: Dado x Informação e Conhecimento apresentado na tabela a seguir:

TABELA 1 | DADO, INFORMAÇÃO E CONHECIMENTO

DADOINFORMAÇÃOCONHECIMENTO

NOMEMarizildoFuncionário da empresa XPTO

INSTITUCIONAL, 2022.

Classificação de dados

Os dados podem ser classificados de duas maneiras: pela fonte de dados ou pelo formato de dados.

Fonte de dados

Quanto à fonte dos dados, que trata do local onde os dados são encontrados, podemos classificar como dados internos ou dados externos.

Os Dados Internos são os dados estruturados, previsíveis, permanentes e fáceis de obter. Exemplo: Sistemas ERP, CRM, BI, SCM, RH.

Os Dados Externos são os dados não estruturados, randômicos, voláteis e difíceis de obter. Exemplo: mídia social, automação, Saas, Paas, APIs, Análise de Textos, Reconhecimento de Voz, Processamento de Linguagem Natural e Internet das Coisas.

Formato de dados

Quanto ao formato dos dados, que trata da apresentação, como os dados surgem, podemos classificar como dados estruturados, dados semiestruturados ou dados não estruturados.

FIGURA 1 | FORMATO DE DADOS

A Figura representa graficamente os três formatos de dados: estruturados, semiestruturados e não estruturados.

Os Dados Estruturados são organizados em linhas e colunas, geralmente presentes nos bancos de dados relacionais, são dados de fácil processamento e recuperação. Esses dados possuem limitações quando precisam tratar grandes volumes de dados. Exemplo: bancos de dados relacionais, Datawarehouse.

Os Dados Semiestruturados são dados que apesar de ter propriedades internas organizadas, não podem ser armazenados em um banco de dados.

Exemplo

Exemplo: código HTML:

<HTML>

<HEAD>UNIDADE CURRICULAR - MODELAGEM DE SOFTWARE</HEAD>

<BODY>

BEM-VINDO AO UNIVERSO DO DADO

</BODY>

</HTML>

Os Dados Não Estruturados não podem ser organizados em linhas e colunas, como vídeos, comentários em redes sociais e e-mails, dentre outros. Geralmente são dados de difícil acesso e recuperação e muitas vezes não dispõem de componentes necessários para identificação de tipo de processamento. Esse tipo de dado foi criado por causa do Big Data (veremos mais adiante).

Banco de Dados

O que você sabe sobre banco de dados?

Banco de Dados é um conjunto de dados integrados que tem por objetivo atender a uma comunidade de usuários (HEUSER, 2011).

Acompanhe algumas definições para banco de dados e que são complementares:

Banco de dados é uma coleção de dados armazenados e organizados de modo a atender as necessidades integradas dos seus usuários. Possibilita a consulta e a manipulação dos dados, podendo ser manual ou computadorizado (PUGA; FRANÇA; GOYA, 2013).

A definição de banco de dados também se amplia ao entender que é uma coleção de dados relacionados. Representa algum aspecto do mundo real, às vezes chamado de minimundo ou universo de discurso (UoD - Universe of Discourse). As mudanças no minimundo são refletidas no banco de dados (ELMASRI; NAVATHE, 2018).

Banco de dados é projetado, construído e populado com dados para uma finalidade específica. Ele possui um grupo definido de usuários e algumas aplicações previamente concebidas nas quais esses usuários estão interessados (ELMASRI; NAVATHE, 2018).

Um banco de dados pode ter qualquer tamanho e complexidade e não necessariamente precisa de um dispositivo eletrônico (computador) para existir.

Exemplo: uma lista de nomes e endereços. Na figura 4 há alguns exemplos do uso do banco de dados em um Controle Bancário, Controle de Livros ou ainda em um Controle de Locação.

FIGURA 2 | EXEMPLOS DE BANCOS DE DADOS

Esses bancos de dados são organizados com a estrutura básica de tabelas, que representam algo do mundo real em que há necessidade de conhecer e armazenar essas informações e colunas, que representam uma característica, propriedade dessa tabela. Cada conjunto de colunas preenchidas será uma linha da tabela, um registro armazenado no banco de dados, conforme exemplifica a tabela a seguir:

TABELA 2 | EXEMPLO TABELA, ATRIBUTO E REGISTRO

FUNCIONÁRIO

NomeSalário

Cariolando dos AnjosR$ 1.045,00

INSTITUCIONAL, 2022.

Funcionalidades do Banco de Dados

Os bancos de dados possuem um conjunto de funcionalidades:

Controle de sincronização

Proteção e recuperação de falhas

Segurança e acesso

Integridade dos dados

Processamento de consultas

Redundância de dados

A redundância de dados ocorre quando os dados são armazenados de forma desnecessária em locais diferentes, o que prejudica a manipulação dos dados, pois cada vez que o dado for alterado haverá retrabalho, localizando todos os lugares em que o mesmo se encontra. A Figura 5 esquematiza a redundância de dados, onde um sistema de cobrança, um sistema de cadastro e um sistema de frequência escolar possuem cada um o seu banco de dados contendo informações sobre estudantes:

FIGURA 3 | EXEMPLO DE REDUNDÂNCIA DE DADOS

Este tipo de abordagem também é conhecido como processamento de arquivos, no qual cada usuário define e implementa os arquivos necessários para uma aplicação de software específica como parte da programação da aplicação (ELMASRI; NAVATHE, 2018). E para resolver o problema de redundância de dados, é feito o compartilhamento dos dados, onde as informações são armazenadas em um único local e acessada por vários sistemas, demonstrado na Figura a seguir no qual um sistema de cobrança, um sistema de cadastro e um sistema de frequência escolar todos acessam o mesmo banco de dados contendo informações sobre estudantes:

FIGURA 4 | EXEMPLO DE COMPARTILHAMENTO DE ARQUIVOS

As principais características de um banco de dados com compartilhamento de dados são (ELMASRI; NAVATHE, 2018):

Autodescrição de um sistema de banco de dados;

Isolamento entre programas e dados e abstração de dados;

Suporte de múltiplas visões dos dados;

Compartilhamento de dados e processamento de transação multiusuário.

Independência dos dados

O dado é o elemento mais estável de um sistema de informação.

No processamento de arquivos tradicional, a estrutura dos arquivos de dados será embutida nos programas de aplicação, de modo que quaisquer mudanças na estrutura de um arquivo podem exigir mudar todos os programas que acessam esse arquivo. Caso contrário, os programas de acesso ao SGBD (Sistema Gerenciador de Banco de Dados) não exigem essas mudanças na maioria dos casos. A estrutura dos arquivos de dados é armazenada no catálogo do SGBD separadamente dos programas de acesso. A esta propriedade chamamos de independência de dados do programa. Abstração de dados é uma característica que permite a independência dos dados em relação aos programas. (ELMASRI; NAVATHE, 2018).

O valor, o conteúdo do dado, se altera, mas o dado dificilmente sofre mudanças. Porém, o processo que, por exemplo, calcula o valor do salário líquido do funcionário pode sofrer modificações devido a uma alteração da lei do governo, por exemplo.

Há interatividade entre o dado e o processo, mas são independentes. Independência de (aplicações em relação aos) dados significa que uma alteração no modelo de dados afeta “pouco” as aplicações.

Exemplo de sistema com pouca independência: Modificação no esquema exige recompilação de todos os programas. As aplicações não contêm descrições dos dados. Com isso, a base de dados pode ser alterada sem que as aplicações sejam modificadas.

Restrições de integridade

Há três tipos de restrições de integridade: integridade referencial, domínio e semântica.

Integridade referencial

Quando a chave estrangeira contém um valor, esse valor se refere a uma Tupla (linha) válida existente em outra relação. Assegura que um valor que aparece em uma relação (tabela) para um determinado conjunto de atributos apareça em outro conjunto de atributos em outra relação (tabela). Como as tabelas em essência são relações, utilizam-se os termos matemáticos relação e tupla, no lugar de tabela e linhas.

Exemplo: se o curso de Computação é um registro que aparece na tabela estudante então deve existir um registro chamado Computação na tabela curso.

A integridade referencial possui características que devem ser atendidas conforme a tabela a seguir:

TABELA 3 | CARACTERÍSTICAS DA INTEGRIDADE REFERENCIAL

INTEGRIDADE REFERENCIALDESCRIÇÃO

EXIGÊNCIAUma chave estrangeira pode ter uma entrada nula, desde que não faça parte da chave primária de uma tabela que esteja relacionada. Ou seja, todo valor não nulo de chave estrangeira DEVE referenciar um valor de chave primária EXISTENTE.

FINALIDADEÉ possível que um atributo NÃO tenha um valor correspondente, mas é impossível que tenha uma entrada inválida. A aplicação da regra de integridade referencial torna impossível a exclusão de uma linha em uma tabela cuja chave primária tenha valores obrigatórios de chave estrangeira em outra tabela.

INSTITUCIONAL, 2022.

Domínio

As restrições de integridade resguardam o Banco de Dados contra danos acidentais, assegurando que mudanças feitas por usuários autorizados não resultem na perda de consistência de dados. Restrições de domínio são a forma mais elementar de restrições de integridade. Estas testam valores inseridos no Banco de Dados, e testam (efetuam) consultas para assegurar que as comparações façam sentido.

Semântica

Há muitas restrições de integridade que não se encaixam nas categorias básicas. Essas restrições são chamadas de restrições semânticas (ou regras de negócio). Também chamada de regras do negócio.

Para aprender mais, temos convênio com a Oracle Academy e há um curso chamado DataBase Foundations que tem o objetivo de descrever as funcionalidades de um banco de dados relacional, usar a modelagem de dados para construir um banco de dados, desenvolver um diagrama entidade-relacionamento para modelar dados, mapear um modelo físico, entre outros.

Sistema gerenciados de Banco de Dados

No início, as linguagens de programação eram responsáveis por definir e manipular os dados. Ou seja, era necessário programar o acesso aos dados. Isso mudou com o surgimento do Sistemas Gerenciador do Banco de Dados (SGBD) ou DataBase Management System (DBMS).

O Sistema Gerenciador de Banco de Dados (SGBD) tem o objetivo de manter grandes repositórios compartilhados de dados, ou seja, manter bancos de dados. É um software que incorpora as funções de definição, recuperação e alteração de dados em um banco de dados (HEUSER, 2011). A figura a seguir esquematiza o papel do SGBD no sistema de computação, onde as aplicações acessam o SGBD e o SGBD acessa o banco de dados.

FIGURA 5 | SGBD

Vantagens no uso de SGBD

O uso do sistema gerenciador de banco de dados tem as seguintes vantagens:

Aumento na produtividade do usuário final;

Minimização da inconsistência dos dados;

Melhoria na integridade dos dados;

Melhoria na tomada de decisão;

Melhoria no compartilhamento de dados;

Melhoria no acesso aos dados.

Características de um SGBD

Para que um software de banco de dados seja considerado um SGBD deve possuir TODAS as características a seguir, do contrário é somente um banco de dados. As características são:

Abstração (o usuário não precisa saber os detalhes como os dados são manipulados ou armazenados no banco de dados);

Controle das Transações (garante a integridade dos dados);

Controle de Concorrência (não permite que dois bancos de dados acessem os dados ao mesmo tempo);

Independência física (dados não dependem do esquema, dos tipos de aplicações que acessam este banco de dados);

Integridade (dependência das chaves);

Não haver redundância de dados;

Padronização dos dados;

Autocontenção (armazenamento dos dados e dos metadados);

Restauração ou reorganização (atomicidade);

Restrições ou consistência (único local de armazenamento);

Visões (limitação que o DBA restringe aos usuários. Segurança e privacidade).

Saiba mais

O(a) Administrador(a) de Banco de Dados (também conhecido como Gerente, Especialista em Banco de Dados ou pela sigla em inglês DBA), é o responsável por desenvolver e monitorar a arquitetura de dados e o banco de dados de uma empresa e/ou seus clientes.

Fonte: http://tutano.trampos.co/16206-guia-de-profissoes-dba/

História do SGBD

No início, o Sistema Gerenciador de Banco de Dados (SGBD) não era desse jeito. Houve várias abordagens, que nada mais é que a maneira como os dados são organizados e como é feita a recuperação dos dados. Os bancos de dados podem ser classificados como TRADICIONAIS e NÃO TRADICIONAIS.

Nos bancos de dados tradicionais as informações são armazenadas e consultadas de forma numérica ou textual. As principais abordagens dos bancos de dados tradicionais – também chamadas por alguns autores de modelo – de banco de dados são: Rede, Hierárquico, Relacional e Orientado a Objetos, conforme a Tabela:

TABELA 4 | TIPOS DE ABORDAGENS OU MODELOS DE BANCO DE DADOS

ABORDAGEMDESCRIÇÃO

HIERÁRQUICO

Surgiu na década de 1960. Organiza os dados em uma estrutura hierárquica (árvore) em um sistema unidirecional de pai para filho, iniciando sempre pela raiz, formado por uma coleção de registros conectados por links e estes registros têm apenas um possuir (pai). Os SGBDs mais conhecidos: IMS, ADABAS e o SYSTEM 2000.

REDE

Surgiu no final da década de 1960. Organiza os dados em uma estrutura formada por várias listas que define uma rede de ligações (grafo direcionado). Os dados são organizados em tipos de registros e ligações entre dois tipos de registros. Os SGBDs mais conhecidos: IDMS, Total.

RELACIONAL Em meados de 1960, Edgar Frank Codd (pesquisador do Laboratório de IBM em San Jose – Califórnia) pesquisava novas formas de manipular grandes volumes de dados. Uma das principais características é a possibilidade de relacionar várias tabelas evitando assim a redundância no armazenamento dos dados.

ORIENTADO A OBJETOS Surgiu a partir da década de 1990. Possui os conceitos da orientação a objetos como encapsulamento, herança e classe. Esses meios de armazenamento se tornaram conhecidos com o crescente uso de linguagens orientadas a objeto.

INSTITUCIONAL, 2022.

Sitema de Banco de Dados

Elmasri e Navathe (2018) explicam que o sistema de banco de dados é a união do banco de dados com o software de SGBD, conforme mostra a figura a seguir:

FIGURA 6 | ESQUEMA DE UM SISTEMA DE BANCO DE DADOS

Os principais softwares de banco de dados no mercado que possuem SGBD são: SQL SERVER, Oracle, MySQL, DB2, Firebird e PostgreSQL.

Já o Microsoft Access não possui todas as características, portanto, é um banco de dados, mas não é um sistema de banco de dados.

Para ser utilizado em um ambiente de banco de dados, o sistema de banco de dados precisa organizar em componentes que definem, regulam, coletam, armazenam e gerenciam os dados. Esse ambiente possui as seguintes partes: HARDWARE, SOFTWARE, PESSOAS, PROCEDIMENTOS e DADOS.

Na tabela a seguir, é apresentado um exemplo comparativo entre processamento de arquivos, SGBD hierárquico, SGBD rede, SGBD relacional e SGBD orientado a objetos:

TABELA 5 | EXEMPLO DE COMPARATIVO ENTRE AS ABORDAGENS DE DADOS

DESCRIÇÃOEXEMPLOARQUIVOSHIERÁRQUICOREDE RELACIONALORIENTADO A OBJETOS

FuncionáriosRelatório contendo informações dos funcionários ARQUIVOTIPO DE SEGMENTOTIPO DE REGISTROTABELACLASSE

Relatório contendo informações dos funcionários Gertrudes FloresREGISTROOCORRÊNCIA DE SEGMENTOREGISTRO ATUALLINHA (TUPLA)INSTÂNCIA DE OBJETO

Data de admissão do funcionário04/06/2000CAMPOCAMPO DE SEGMENTOCAMPO DE REGISTROATRIBUTO DE TABELAATRIBUTO DO OBJETO

Identificação do funcionário1234ÍNDICECAMPO DE SEQUÊNCIACHAVE DE REGISTROCHAVEIDENTIFICADOR DE OBJETO

INSTITUCIONAL, 2022.

A linguagem padrão dos bancos de dados tradicionais é a Structured Query Language (SQL), linguagem de consulta estruturada, presente nos bancos de dados do tipo relacional e orientado a objetos.

Mas com o crescimento dos dados não estruturados nas redes sociais e web, surgiu um novo conceito chamado NoSQL.

NoSQL

NoSQL significa Not Only SQL (Não é Apenas SQL) que são sistemas para gerenciar grandes volumes de dados. Os bancos de dados NoSQL são bancos de dados não relacionais que são usados com a tecnologia Big Data e oferecem uma arquitetura muito mais escalável e eficiente que os bancos de dados relacionais para este tipo de dado.

Exemplo

Como exemplo de softwares de banco de dados com a tecnologia NoSQL destaca-se: MongoDB, Cassandra, HBase, CouchDB, entre outros.

Para aprofundar seu conhecimento, confira a leitura indicada a seguir.

Estudo Guiado

Leia páginas 795 a 820

Clique no link e leia o livro

ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 7. ed. São Paulo: Pearson, 2018.

Big Data

FIGURA 7 | BIG DATA

Big Data, termo usado quando há o uso de uma grande quantidade de dados com diferentes fontes e formatos. Trata-se de um conjunto de dados cujo tamanho vai além da capacidade típica das ferramentas de software de banco de dados. Atualmente possui cinco características, chamadas de 5 Vs: Valor, Variedade, Velocidade, Veracidade e Volume descritas na tabela a seguir:

TABELA 6 | CARACTERÍSTICAS DO BIG DATA

CARACTERÍSTICADESCRIÇÃO

VALOROs dados devem apoiar a tomada de decisão.

VARIEDADEGrande variedade de dados proveniente de diversas fontes estruturadas ou não estruturadas.

VELOCIDADERapidez como são produzidos os dados e precisam ser analisados.

VERACIDADEVerificar se os dados coletados realmente são úteis. Há muita informação na Internet que não é verdadeira.

VOLUMEOs dados são produzidos e coletados grandes volumes de dados.

INSTITUCIONAL, 2022.

Há uma variedade de soluções atualmente para o Big Data e cresce gradativamente todo ano.

É possível encontrar o Big Data em diversas aplicações, por exemplo: carros automatizados, combate ao crime e ao terrorismo, detecção de fraudes, detecção de terremotos, detecção e prevenção de epidemias, educação customizada, por demanda e on-line, geomarketing através de smartphones, marketing personalizado, entre outros.

Para aprofundar seu conhecimento, confira a leitura indicada a seguir.

Estudo Guiado

Leia as páginas 821 a 861

Clique no link e leia o livro

ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 7. ed. São Paulo: Pearson, 2018.

Para conhecer mais sobre Big Data, com Dados Estruturados, Semiestruturados, Não Estruturados e Ciência de Dados, indicamos cursos gratuitos de 8 horas cada, via web, não possuem pré-requisito, em português e com emissão de certificado.

Saiba mais

Curso: Big Data Fundamentos, disponível de forma gratuita na Data Science Academy, disponível através do site: https://www.datascienceacademy.com.br/course?courseid=big-data-fundamentos

Curso: Introdução à Ciência de Dados, também disponível de forma gratuita na Data Science Academy, disponível através do site: https://www.datascienceacademy.com.br/course?courseid=introduo--cincia-de-dados

Profissões relacionadas a Banco de Dados

Na tabela a seguir, apresentamos as principais profissões relacionadas a banco de dados:

TABELA 7 | PROFISSÕES RELACIONADAS A BANCO DE DADOS

PROFISSÃODESCRIÇÃO

ADMINISTRADOR DE BANCO DE DADOSSuporte técnico aos bancos de dados existentes; Personalização de bancos de dados comerciais para necessidades específicas; Planejamento e projeto de bancos de dados para necessidades específicas; Solução de problemas para atender as necessidades dos clientes; Desenvolvimento de banco de dados para uma ampla variedade de aplicações; Supervisão da instalação de novos SGBD; Criar procedimentos de backup, restauração e recuperação de desastres; Atuar com bancos de dados relacionais e não relacionais.

ANALISTA DE DADOSTrabalhar com as equipes de TI, gestão e/ou cientistas para determinar os objetivos organizacionais; Coletar dados de fontes primárias e secundárias; Realizar limpeza nos dados e descartar informações irrelevantes; Analisar e interpretar os resultados utilizando ferramentas estatísticas e técnicas convencionais; Identificar novas oportunidades para melhoria de processos; Fornecer relatórios de dados concisos e visualizações de dados claros para a gestão; Concepção, criação e manutenção de banco de dados relacionais e NoSQL e sistemas de banco de dados; Resolver problemas de código e questões relacionadas a dados; Dominar linguagens (R, Python, SQL) e softwares de análise de dados (SAS, Tableau, Qlik).

ANALISTA DE NEGÓCIOSEstabelecer os objetivos e o âmbito de sistemas de negócios e de TI; Identificar problemas organizacionais e conceber soluções orientadas a dados; Realizar análises estatísticas, pesquisas, oficinas de formação e testes; Recomendar mudanças nos processos, pessoal ou ofertas de produtos para tornar os departamentos internos mais eficientes; Conceber novos sistemas ou alterar os existentes; Fazer recomendações específicas de TI e apoiar a sua implementação; Agir como um elo de ligação entre os gestores e equipes técnicas; Propor suas decisões baseadas em dados.

ARQUITETO DE DADOSColaborar com as equipes de TI e gestão para elaborar uma estratégia de dados que atenda aos requisitos da empresa; Criar um inventário de dados necessários para implementar a arquitetura; Pesquisar novas oportunidades de aquisição de dados; Identificar e avaliar as atuais tecnologias de gerenciamento de dados; Criar um fluxo de dados dentro da empresa; Desenvolver modelos de dados; Projetar, documentar, construir e implementar arquiteturas e aplicações de banco de dados, por exemplo, grandes bancos de dados relacionais e NoSQL; Integrar a funcionalidade técnica, por exemplo: escalabilidade, segurança, desempenho, recuperação de dados, confiabilidade etc. Implementar medidas para assegurar a precisão dos dados e acessibilidade; Monitorar constantemente, aperfeiçoar e apresentar um relatório sobre o desempenho dos sistemas de gerenciamento de banco de dados.

CIENTISTA DE DADOSComunicar previsões e resultados para a gestão e os departamentos de TI através de visualizações de dados eficazes; Extrair grandes volumes de dados de múltiplas fontes internas e externas; Empregar os programas de análise sofisticadas, aprendizado de máquina e métodos estatísticos para preparar os dados para uso em modelagem preditiva e prescritiva; Explorar e analisar dados de uma variedade de ângulos para determinar fraquezas escondidas, tendências e/ou oportunidades; Conceder soluções orientadas a dados para os principais desafios da empresa; Criar algoritmos para resolver problemas e criar ferramentas para automatizar o trabalho; Recomendar mudanças econômicas aos procedimentos e estratégias existentes; Dominar técnicas de análise e armazenamento de dados.

ENGENHEIRO DE DADOSResponsável pela arquitetura e infraestrutura de dados que trabalha com design, construção e manutenção de sistemas para armazenamento e processamento de dados.

PROJETISTA OU ADMINISTRADOR DE BANCO DE DADOSIdentificação das necessidades de informações da organização; Retirar da equipe de desenvolvimento a responsabilidade da organização e estruturação dos dados, trabalhando na análise e descrição geral de dados, na definição do modelo conceitual, no projeto lógico do banco de dados e, ainda, na análise funcional dos dados; Garantia da validade, exatidão, consistência e da disponibilidade dos dados; Promoção do compartilhamento dos dados da organização; Disponibilidade de informações suficientes que facilitem o uso e a compreensão dos dados; Refinamento das informações da organização visando melhorar a sua qualidade e performance de acesso; Impedimento do crescimento desordenado de objetos da base de dados; Tomada de medidas preventivas e corretivas para identificação de problemas existentes no modelo de dados da organização; Fornecimento de suporte na compreensão e utilização dos dados à equipe de desenvolvimento; Manutenção dos modelos de informações atualizados.

INSTITUCIONAL, 2022.

Saiba mais

SALÁRIOS NA ÁREA DE TECNOLOGIA

O Guia Salarial da Robert Half é uma das mais respeitadas fontes de informação sobre remuneração e tendências de recrutamento para auxiliar empresas e profissionais a tomarem as melhores decisões e publicada anualmente um guia salarial disponível gratuitamente em: https://www.roberthalf.com.br/guia-salarial

Projeto de Banco de Dados

Chamamos de projetista de banco de dados ou administrador de dados, o responsável por criar o projeto de banco de dados.

Um projetista de banco de dados define toda a estrutura de armazenamento e elementos necessários para o banco de dados.

Um projetista deve ter conhecimento sobre:

Análise orientada a objetos;

Avaliar as necessidades dos usuários;

Entendimento da linguagem e do ambiente de desenvolvimento;

Modelagem de banco de dados;

Técnicas de projeto de banco de dados.

Todo bom sistema de banco de dados deve apresentar um projeto, que visa à organização das informações e utilização de técnicas para que o futuro sistema obtenha boa performance e também facilite infinitamente as manutenções que venham a acontecer. Um sistema de informação utiliza um banco de dados que necessita de DADOS e PROCESSOS, onde

Recurso lista interativa:

DADOS

PROCESSOS

Conteúdo

DADOS:

Parte mais estável do sistema, após definido pouco se modifica (objeto desta Unidade Curricular);

O PROJETO DE BANCO DE DADOS tem o objetivo de transformar as necessidades de informações no negócio em um banco de dados. Ou seja, foca na maneira em que o banco de dados será usado para armazenar e gerenciar os dados do usuário final e a primeira etapa é criar o modelo de dados.

O projeto de um novo banco de dados dá-se em três fases: Modelo Conceitual, Modelo Lógico e Modelo Físico de Dados. As duas primeiras fases (Modelo Conceitual e Dados e Modelo Lógico de Dados) são níveis de abstração na construção do modelo de dados (HEUSER, 2011).

O projeto de um novo banco de dados começa em uma fase chamada especificação e análise de requisitos (ELMASRI; NAVATHE, 2018).

Esses requisitos são documentados com detalhes e transformados em um projeto conceitual, que pode ser representado e manipulado com o uso de algumas ferramentas computadorizadas, de modo que possa ser facilmente mantido, modificado e transformado em uma implementação de banco de dados. Esse projeto é então traduzido para um projeto lógico que pode ser expresso em um modelo de dados implementado em um sistema gerenciador de banco de dados (SGBD). A última etapa é o projeto físico, durante o qual outras especificações são fornecidas para armazenar e acessar o banco de dados. Então o projeto de banco de dados é implementado, preenchido com dados reais e mantido para refletir o estado do minimundo. (ELMASRI; NAVATHE, 2018).

A figura a seguir esquematiza as etapas do projeto de banco de dados.

FIGURA 8 | ETAPAS DO PROJETO DE BANCO DE DADOS

A definição ou informação descritiva do banco de dados também é armazenada no SGBD na forma de um catálogo ou dicionário, chamado de metadados. Um banco de dados representa algum aspecto do mundo real, às vezes chamado de minimundo ou de universo de discurso (UoD). As mudanças no minimundo são refletidas no banco de dados (ELMASRI; NAVATHE, 2018).

Vamos conhecer cada etapa deste projeto e suas características, na tabela a seguir:

TABELA 8 | ETAPAS DO PROJETO DE BANCO DE DADOS

ETAPADESCRIÇÃO

PROJETO CONCEITUAL

Modelo abstrato de banco de dados de acordo com a visão da empresa.

Agrupa os elementos de dados no banco de dados.

Identifica elementos redundantes e os grupos de elementos de dados repetidos para aplicações específicas.

É uma das etapas mais importantes do projeto.

Cria-se o Modelo Entidade Relacionamento (MER).

PROJETO LÓGICO

Mapeia o modelo conceitual para um modelo lógico.

Padroniza de acordo com a implementação, adequando ao tipo de abordagem de SGBD.

PROJETO FÍSICOCriação dos objetos no software de banco de dados através de scripts, usando a linguagem SQL (Structured Query Language - Linguagem de Consulta Estruturada).

INSTITUCIONAL, 2022.

Atenção!

Há ainda outra forma de mostrar as informações do projeto chamado de ESQUEMA RELACIONAL que é uma representação textual de uma tabela (também chamado de relação) na abordagem relacional, onde os atributos aparecem entre parênteses e os atributos-chave aparecem sublinhados ou negrito. Ex.: ESTUDANTE (matricula, nome, data_de_nascimento, estado_civil).

Modelo de Dados

Um modelo de dados é descrição formal da estrutura de um banco de dados (HEUSER, 2011).

Modelo de (banco de) dados é uma descrição dos tipos de informações que estão armazenadas em um banco de dados. Por exemplo, no caso da indústria acima citado, o modelo de dados poderia informar que o banco de dados armazena informações sobre produtos e que, para cada produto, são armazenados seu código, preço e descrição. Observe que o modelo de dados não informa quais os produtos que estão armazenados no banco de dados, mas apenas que o banco de dados contém informações sobre produtos. (HEUSER, 2011).

O conjunto de conceitos usados na construção de um modelo dá-se o nome de ABORDAGEM DE MODELAGEM (HEUSER, 2011).

Recurso lista interativa:

Os benefícios da modelagem de dados são:

Conteúdo

Os benefícios da modelagem de dados são: :

Entendimento do Negócio;

Comunicação;

Estruturação dos Dados;

Definição de Escopo;

Estimativas de prazos e custos.

Para aprofundar seu conhecimento, confira a leitura indicada a seguir.

Estudo Guiado

Leia páginas 19 a 29 do livro Projeto de Banco de Dados - Capítulo 1 - Introdução.

HEUSER, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2011.

Exemplos das etapas do projeto de Banco de Dados

O estudo de caso apresentado tem o objetivo de apresentar as etapas do projeto de banco de dados:

Estudo de caso

CLÍNICA MÉDICA

Uma especialidade médica possui vários médicos, por exemplo, clínica geral, pediatria entre outros. Há médicos, que podem ter mais de uma especialidade, por exemplo, um médico que é alergologista e também homeopata. Para isso, como dados a serem armazenados temos a sigla e o nome da especialidade médica e dos médicos temos o CRM, o nome e o telefone para contato.

Modelo conceitual de Dados

Nesta primeira etapa, criamos o Modelo Entidade e Relacionamento (M.E.R.) que demonstra as entidades com seus atributos (dados) e os relacionamentos entre essas entidades. A figura a seguir mostra a resolução do estudo de caso no modelo conceitual de dados:

FIGURA 9 | MODELO CONCEITUAL DE DADOS

Modelo lógico de Dados

Nesta etapa, criamos o Modelo Lógico de Dados que demonstra as entidades com seus atributos (dados) e os relacionamentos entre essas entidades. A figura a seguir mostra a resolução do estudo de caso no modelo lógico de dados, adequado para a abordagem relacional com os tipos de dados da linguagem SQL:

FIGURA 10 | EXEMPLO MODELO LÓGICO DE DADOS

Modelo físico de Dados

Na última etapa, é criado o Modelo Físico de Dados, onde é gerado o script (código contendo os comandos) da criação das tabelas com os campos e relacionamentos, baseado na linguagem SQL (Structured Query Language). A Figura exemplifica o script contendo a criação de tabelas com restrições de chave primária e chave estrangeira:

FIGURA 11 | MODELO FÍSICO DE DADOS

Esquema relacional

É possível representar o esquema relacional das tabelas utilizando a notação de relação, onde os atributos-chave são diferenciados por estar em negrito ou sublinhado, conforme exemplo abaixo:

Seite 7

MODELO CONCEITUAL DE DADOS

Como você já percebeu pela história em quadrinhos, a nossa unidade terá como foco principal o Modelo Conceitual de Dados, que tem o objetivo de mostrar as informações que precisam ser armazenadas no banco de dados, com suas características e relacionamentos entre elas.

Ao final deste conteúdo, você será capaz de:

Reconhecer os componentes do modelo de dados em nível conceitual.

Elaborar abstrações de dados em modelos conceituais.

Desenhar modelos conceituais de dados.

Bons estudos!

Modelo conceitual de dados

O conceito do Modelo Entidade Relacionamento (MER) foi proposto por Peter Chen, nos anos 70, e tem como base a perspectiva do mundo real como constituído por um conjunto de objetos, chamados de entidades e relacionamentos. Além disso, esse modelo se vale de uma técnica de diagramação capaz de representar o modelo de dados, de forma abrangente por meio do Diagrama Entidade Relacionamento (DER). Essa proposta se mostrou tão eficiente, simples e completa que, ainda hoje, é muito utilizada para formalizar o conhecimento de negócio e facilitar o projeto do banco de dados. O MER é um dos modelos de maior capacidade semântica - os aspectos semânticos se referem à tentativa de representar o significado dos dados. O MER também é extremamente útil para mapear, a partir de um esquema conceitual, o significado e as interações das empresas reais (PUGA; FRANÇA; GOYA, 2013).

Saiba mais

Para conhecer mais sobre o pesquisador Peter Chen e suas contribuições para o Modelo Entidade e Relacionamento, acesse:

https://bit.csc.lsu.edu/~chen/chen.html

O modelo conceitual de dados é uma descrição do banco de dados, de forma independente de implementação em um SGBD. O modelo conceitual registra que dados podem aparecer no banco de dados, mas não registra como eles estão armazenados a nível de SGBD (HEUSER, 2011).

A modelagem conceitual é uma fase muito importante no projeto de uma aplicação de banco de dados bem-sucedida. Geralmente, o termo aplicação de banco de dados refere-se a um banco de dados em particular e aos programas associados que implementam suas consultas e atualizações. Com os requisitos levantados e analisados, a próxima etapa é criar um esquema conceitual para o banco de dados, usando um modelo de dados conceitual de alto nível. Essa etapa é chamada de projeto conceitual. O esquema conceitual é uma descrição concisa dos requisitos de dados dos usuários e inclui detalhes dos tipos de entidade, relacionamentos e restrições (ELMASHRI; NAVATHE, 2018).

Tem o objetivo de registrar os dados que podem aparecer em um banco de dados, mas não registra como esses dados estão armazenados no SGBD, ou seja, o modelo de dados abstrato que descreve a estrutura de um banco de dados de forma independente do SGBD.

Possui as seguintes funções:

entender o funcionamento de processos e regras de negócio;

expressar as necessidades de informações da empresa como um todo;

facilitar a comunicação entre áreas usuárias e de Tecnologia da Informação (TI);

definir a abrangência do sistema, delimitando o escopo e estimulando custos e prazos para a elaboração do projeto;

avaliar soluções de software, no momento de aquisição, por meio da comparação entre o que a solução pode oferecer e a visão do modelo de dados conceitual;

permitir estruturar os dados com flexibilidade;

representar os principais elementos envolvidos no contexto do negócio mostrando uma visão de alto nível do banco de dados.

A partir do entendimento do negócio, elabora-se o modelo conceitual dos dados. Nesse modelo, não são considerados aspectos relacionados ao SGBD que serão utilizados, e busca-se uma representação em alto nível de como será o banco de dados.

Na etapa do modelo conceitual, identifica-se a informação (conjunto de dados) necessária para determinada tarefa.

A técnica mais difundida é a ABORDAGEM ENTIDADE-RELACIONAMENTO, através do MER, utilizando como representação gráfica o DIAGRAMA DE ENTIDADE-RELACIONAMENTO (DER) (HEUSER, 2011).

O Diagrama de Entidade-Relacionamento possui os seguintes componentes na sua notação:

Entidades (relação)

Atributos

Relacionamentos

Vamos ver cada um desses componentes na sua especificidade:

Entidades

Entidades são grupos de ocorrências com definição específica, características e relacionamentos comuns. Ocorrência são valores, isto é, os dados em si, sendo específicos da entidade. Uma ocorrência também é conhecida como instância, tupla ou registro. A entidade pode ser caracterizada como: objeto ou fato que deve ter seus dados guardados em um determinado contexto, conjunto de um tipo de informação que seja diretamente associado ao domínio de conhecimento analisado, objeto que desempenha um papel específico no sistema e objeto que possui propriedades que o distinguem de outras entidades, podendo ser: objeto (concreto, como computador, veículo, produto, imóvel, etc.), pessoa (funcionário cliente, estudante, etc.), evento (situação em que algo está ocorrendo ou está planejado para ocorrer, programação de voos, planejamento de vendas, consulta médica, etc.) (PUGA; FRANÇA; GOYA, 2013).

As entidades, também chamadas de relação, representa a categoria de elementos relevantes para o negócio, podendo ser, por exemplo, estudantes e professores. Pode ser um objeto concreto ou abstrato (aluno ou curso). A Figura a seguir, mostra a notação para entidade CLIENTE que é representado por um retângulo:

FIGURA 1 | REPRESENTADO DA ENTIDADE

As entidades podem ser classificadas, segundo o motivo de sua existência, como: entidade fraca e entidade forte.

Entidades fortes

Entidades fracas

A Figura a seguir, exemplifica a entidade fraca:

FIGURA 2 | EXEMPLO ENTIDADE FRACA

Atributos

Os atributos descrevem as características ou propriedades de uma entidade. Os tipos de atributos são: atributo simples, atributo identificador, atributo multivalorado e atributo composto. O atributo simples possui duas notações: atributos com elipse e atributos com círculo, conforme apresentado na Figura a seguir:

FIGURA 3 | NOTAÇÃO ATRIBUTO SIMPLES

A seguir, descreveremos cada tipo de atributos:

Atributo identificador

O atributo identificador é uma característica única e com preenchimento obrigatório que determina como único aquele registro na entidade. O atributo identificador no registro_acadêmico possui duas notações: elipse com o nome do atributo sublinhado e o círculo preenchido, conforme apresentado na Figura a seguir:

FIGURA 4 | NOTAÇÃO DO ATRIBUTO IDENTIFICADOR

Atributo multivalorado

O atributo multivalorado é quando a característica pode ter nenhum (0), um (1) ou vários valores (n). O atributo multivalorado possui duas notações: usando a elipse e o círculo com a cardinalidade mínima e máxima no telefone, conforme apresentado na Figura a seguir:

FIGURA 5 | NOTAÇÃO ATRIBUTO MULTIVALORADO

Atributo composto

Atributo composto é formado não somente por atributos da própria entidade, mas também por relacionamentos dos quais a entidade participa (relacionamento identificador). O atributo composto possui duas notações com elipse e círculo, onde o nome do endereço é composto pelos atributos logradouro, número e complemento (HEUSER, 2011), conforme apresentado na Figura a seguir:

FIGURA 6 | NOTAÇÃO ATRIBUTO COMPOSTO

O terceiro comente do Diagrama de Entidade-Relacionamento é o Relacionamentos. Acompanhe!

Relacionamentos

Relacionamento é um conjunto de associações entre ocorrências de entidades. Os relacionamentos ocorrem entre os atributos, mas são representados como relacionamentos entre as entidades. Os relacionamentos podem ser classificados pelo seu grau (HEUSER, 2011).

Grau de um tipo de relacionamento é o número dos tipos de entidade participantes. Quando o relacionamento possui duas entidades, ou seja, grau dois, é chamado de relacionamento binário (ELMASRI; NAVATHE, 2018), conforme mostra a Figura a seguir, entre as entidades SETOR e FUNCIONÁRIO:

FIGURA 7 | EXEMPLO RELACIONAMENTO BINÁRIO

O relacionamento binário anterior lê-se:

Um SETOR aloca um ou vários (n) FUNCIONÁRIOS.

Vários (n) FUNCIONÁRIOS são alocados em somente um SETOR.

A cardinalidade máxima pode ser usada para classificar relacionamentos binários. Um relacionamento binário é aquele cujas ocorrências contêm duas ocorrências de entidade, como todos os vistos até aqui. Podemos classificar os relacionamentos binários em n:n (ou m:n), 1:n e 1:1 (HEUSER, 2011).

Quando possui três entidades participantes é chamado de relacionamento ternário (ELMASRI; NAVATHE, 2018), conforme mostra a Figura a seguir, entre as entidades CIDADE, DISTRIBUIDOR e PRODUTO:

FIGURA 8 | EXEMPLO RELACIONAMENTO TERNÁRIO

O relacionamento ternário anterior lê-se:

Uma ou várias CIDADES distribuem um ou vários PRODUTOS.

Um ou vários PRODUTOS são distribuídos por uma ou várias CIDADES.

Um ou vários DISTRIBUIDORES distribuem um ou vários PRODUTOS.

Um ou vários PRODUTOS são distribuídos por um ou vários DISTRIBUIDORES.

Relacionamentos Recursivos também são chamados de autorrelacionamentos. Ocorre quando cada tipo de entidade, e que participa de um tipo de relacionamento, é desempenhado em cada instância de relacionamento. Para identificá-lo, usamos os nomes de papéis para distinguir os papéis diferentes em um relacionamento entre a mesma entidade (ELMASRI; NAVATHE, 2018). A Figura a seguir, exemplifica o relacionamento recursivo com a entidade PESSOA contendo dois papéis: esposa e esposo no relacionamento CASAMENTO:

FIGURA 9 | EXEMPLO RELACIONAMENTO RECURSIVO

O relacionamento recursivo anterior lê-se:

Uma PESSOA em um relacionamento como CASAMENTO ocupa dois papéis distintos: esposa e pessoa.

Cardinalidade

Para fins de projeto de banco de dados, uma propriedade importante de um relacionamento é a de quantas ocorrências de uma entidade podem estar associadas a uma determinada ocorrência através do relacionamento. Essa propriedade é chamada de cardinalidade. Há duas a considerar: a cardinalidade máxima e a cardinalidade mínima (HEUSER, 2011).

A cardinalidade (mínima ou máxima) de entidade em relacionamento refere-se ao número de ocorrências de entidade associadas a uma ocorrência da entidade em questão, através do relacionamento, onde a cardinalidade mínima pode ser 0 ou 1, e a cardinalidade máxima pode ser 1 ou vários (N) registros. Quando a cardinalidade mínima é 0, significa que é opcional (HEUSER, 2011).

Relacionamentos binários

Os relacionamentos binários entre as entidades podem ser 1 para 1; 1 para muitos (N) e de muitos (M ou N) para muitos (N). A seguir, vamos conhecer cada um dos relacionamentos.

Relacionamento 1 para 1 e relacionamento 1 para N

Os relacionamentos entre as entidades do tipo 1 para 1 e 1 para N são representados por um losango, conforme a notação na Figura a seguir:

FIGURA 10 | NOTAÇÃO RELACIONAMENTO 1:1 E RELACIONAMENTO 1:N

Na Figura a seguir, exemplificamos um modelo conceitual de dados com relacionamento de 1 para 1. Quando dizemos que há um relacionamento de 1 para 1, estamos nos referindo à cardinalidade MÁXIMA do relacionamento em cada uma das entidades envolvidas, podendo a cardinalidade mínima ser 0 ou 1.

FIGURA 11 | EXEMPLO RELACIONAMENTO 1:1

O relacionamento 1:1 apresentado na Figura 12 lê-se:

Um COORDENADOR coordena um CURSO.

Um CURSO é coordenado por um COORDENADOR.

Na Figura a seguir, exemplificamos um modelo conceitual de dados com relacionamento de 1 para N. Quando dizemos há um relacionamento de 1 para N, estamos nos referindo à cardinalidade MÁXIMA do relacionamento em cada uma das entidades envolvidas, podendo a cardinalidade mínima ser 0 ou 1.

FIGURA 12 | EXEMPLO RELACIONAMENTO 1 PARA N

O relacionamento 1:N apresentado na Figura apresentada lê-se:

Um CURSO matricula um ou vários ALUNOS.

Um ou vários ALUNOS se matriculam em um CURSO.

Relacionamento N para N

O relacionamento N para N (ou M para N) é chamado de ENTIDADE ASSOCIATIVA e poderá ter atributos próprios. Sua notação é representada com um losango dentro de um retângulo na Figura a seguir:

FIGURA 13 | NOTAÇÃO RELACIONAMENTO N:N

Na Figura a seguir, exemplificamos um modelo conceitual de dados com relacionamento de N para N. Quando dizemos há um relacionamento de 1 para N, estamos nos referindo à cardinalidade MÁXIMA do relacionamento em cada uma das entidades envolvidas, podendo a cardinalidade mínima ser 0 ou 1.

FIGURA 14 | EXEMPLO RELACIONAMENTO N:N

O relacionamento N : N apresentado na Figura apresentada lê-se:

Um PACIENTE é consultado por um ou vários MÉDICOS;

Um ou vários MÉDICOS consultam um ou vários PACIENTES.

Modelo estendido ou expandido

O modelo entidade-relacionamento estendido ou expandido (EER) inclui os conceitos de superclasse e subclasse, e os conceitos de especialização/generalização, também chamado de MER-X. A Figura 16 explica a especialização e a generalização onde a classe genérica abstrai, e a entidade específica detalha:

FIGURA 15 | EXEMPLO GENERALIZAÇÃO E ESPECIFICAÇÃO

Associada ao conceito de generalização/especialização está a ideeia de herança de propriedades. Herdar propriedades significa que cada ocorrência da entidade especializada possui, além de suas próprias propriedades (atributos, relacionamentos e generalizações/especializações) as propriedades da ocorrência da entidade genérica correspondente (HEUSER, 2011).

São caracterizados como: ESPECIALIZAÇÃO e GENERALIZAÇÃO:

Recurso lista interativa:

Especialização

Generalização

Conteúdo

Especialização:

Processo de definir um conjunto de subclasses de um tipo entidade, chamada de superclasse da especialização.

Voltar para a navegação do recurso lista interativa

A herança pode ser classificada ainda, como: TOTAL, PARCIAL ou COMPARTILHADA:

TOTAL: para cada entidade genérica existe sempre uma ocorrência na específica. A Figura a seguir exemplifica:

FIGURA 16 | EXEMPLO HERANÇA TIPO TOTAL

O CLIENTE ou é tipo PESSOA FÍSICA ou é tipo PESSOA JURÍDICA.

FIGURA 17 | HERANÇA TIPO PARCIAL

PARCIAL

Nem toda ocorrência da entidade genérica possui uma ocorrência correspondente em uma entidade específica. A Figura apresentada aqui, exemplifica que uma entidade FUNCIONÁRIO pode ser MOTORISTA, SECRETÁRIA ou ter qualquer outra função que não está especificada.

FIGURA 18 | HERANÇA TIPO COMPARTILHADA

COMPARTILHADA

Indica uma hierarquia, uma ocorrência da entidade genérica pode aparecer em várias entidades. A Figura apresentada aqui, exemplifica que a entidade PESSOA pode ser PROFESSOR e também ALUNO ou ALUNO e também FUNCIONÁRIO.

Herança múltipla

Herança múltipla ocorre quando uma mesma entidade é uma especialização de diversas entidades genéricas. A Figura a seguir, exemplifica a herança múltipla (HEUSER, 2011).

A entidade AUTOMÓVEL herda características da entidade TERRESTRE, que, por sua vez, herda características da entidade VEÍCULO.

A entidade BARCO herda características da entidade AQUÁTICO, que, por sua vez, herda características da entidade VEÍCULO.

E a entidade ANFÍBIO herda características das entidades TERRESTRE e AQUÁTICO, que, por sua vez, herda características da entidade VEÍCULO.

FIGURA 19 | EXEMPLO HERANÇA MÚLTIPLA

Para aprofundar seu conhecimento, confira a leitura indicada a seguir.

Estudo Guiado

Leia as páginas 35-65, capítulo 2 - Abordagem Entidade-Relacionamento, do livro 'Projeto de Banco de Dados', do Heuser (2011).

Clique no link e leia o livro

HEUSER, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2009.

Software brmodelo

Curiosidade

O Software BR Modelo foi desenvolvido, em 2005, como um...

O Software BR Modelo foi desenvolvido, em 2005, como um projeto de conclusão de pós-graduação em banco de dados, sob a orientação do prof. Dr. Ronaldo dos Santos Melo (UFSC), com o objetivo de criar uma ferramenta que fizesse o modelo conceitual de dados.

O Software brModelo é um software gratuito desenvolvido para o aprendizado de modelagem de banco de dados e está fortemente acoplado aos conceitos de construção de modelos/esquemas adotados pelo Dr. Carlos Alberto Heuser (2011), em seu livro "Projeto de Banco de Dados" (livro disponível na Biblioteca Virtual - minha Biblioteca) e este software não possui necessidade de instalação.

Saiba mais

Software BrModelo versão 3.0

https://sourceforge.net/projects/brmodelo30/

https://baixe.net/baixar/down4374.html

https://baixe.net/brmodelo-3-0

Vamos explicar cada um dos comandos relevantes para a construção do Diagrama Entidade Relacionamento no BrModelo.

A Figura a seguir, apresenta a tela principal do software BrModelo 3.0.

FIGURA 20 | TELA PRINCIPAL BR MODELO VERSÃO 3.0

A seguir, vamos conhecer os recursos do software BrModelo no Esquema Conceitual e no Esquema Lógico de Dados:

FIGURA 21 | BR MODELO - MENU ARQUIVO

BrModelo - Menu Arquivo

Este menu possui duas opções importantes:

Novo Modelo: selecionar o Modelo Conceitual ou o Modelo Lógico.

Imprimir: selecionar o formato que deseja salvar o diagrama.

FIGURA 22 | OPÇÕES DE ESQUEMA CONCEITUAL

FIGURA 23 | PROPRIEDADES - ESQUEMA CONCEITUAL

FIGURA 24 | OPÇÕES ESQUEMA LÓGICO

Vamos ver um estudo de caso completo para conhecer todos os recursos deste software.

Estudo de caso

Uma instituição de ensino deseja armazenar no banco de dados informações sobre alunos, mensalidades, cursos, professores e unidades curriculares oferecidas, com o seguinte:

Cursos: nome e carga horária.

Alunos: registro_acadêmico, nome, endereço, telefones e data de nascimento.

Professores: identificação e nome.

Unidade_Curricular: sigla, nome e carga horária.

Mensalidades: data da emissão, data de vencimento e data de pagamento e valor.

Regra de Negócio: Um curso pode ter vários alunos. Porém, um aluno faz um curso por vez e, para isso, terá um novo registro_acadêmico. Cada curso possui várias unidades curriculares, e estas podem estar presentes em vários cursos. Um professor leciona várias unidades curriculares, e uma unidade curricular também pode ter vários professores. Com isso, um aluno possui várias mensalidades, e uma mensalidade pertence a um aluno, que é emitida todo mês.

Seguem os passos para a resolução deste estudo de caso:

Localizar as Entidades (normalmente substantivos que possuem propriedades, características).

Localizar os Atributos, características que pertencem a cada Entidade.

Localizar os Atributos Identificadores de Cada Entidade (características únicas que são obrigatórias estar preenchidas). OBS.: se não houver um atributo que possa ser usado como identificador, criar um atributo (isto é chamado de artificial).

Verificar se há atributos multivalorados (características que podem ter nenhum ou vários conteúdos distintos da mesma informação).

Verificar se há atributos compostos (característica composta por um conjunto de características).

Localizar os relacionamentos entre Entidades. OBS.: a ordem da criação das entidades é importante, pois uma entidade pode depender da outra entidade.

Verificar se há entidades associativas (relacionamento entre entidades na cardinalidade de muitos para muitos).

1. Localizar as Entidades:

CURSO, UNIDADE_CURRICULAR, ALUNO, PROFESSOR, MENSALIDADE.

2. Localizar os Atributos:

CURSO: nome_curso e carga_horária.

ALUNO: registro_acadêmico, nome_aluno, endereço, telefone e data_nascimento.

PROFESSOR: código e nome_professor.

UNIDADE_CURRICULAR: sigla, nome_unidade_curricular e carga_horária.

MENSALIDADE: data_ emissão, data_vencimento, data_pagamento e valor_mensalidade.

3. Localizar os Atributos Identificadores de Cada Entidade:

CURSO: código.

ALUNO: registro_acadêmico.

PROFESSOR: código.

UNIDADE_CURRICULAR: sigla.

MENSALIDADE: data_emissão.

4. Verificar se há atributos multivalorados:

ALUNO - telefone (pode ser zero ou vários (0,n)).

5. Verificar se há atributos compostos:

ALUNO - endereço composto por: logradouro, numero, complemento, bairro, cidade, unidade_federativa, CEP.

6. Localizar os relacionamentos entre Entidades:

CURSO com ALUNO.

CURSO com UNIDADE_CURRICULAR.

UNIDADE_CURRICULAR com PROFESSOR.

ALUNO com MENSALIDADE.

7. Verificar se há entidades associativas:

CURSO com UNIDADE_CURRICULAR.

UNIDADE_CURRICULAR com PROFESSOR.

Atenção!

No modelo conceitual de dados, não é necessário colocar o tipo de dado de cada atributo (será visto com maiores detalhes na Unidade de Ensino Modelo Físico de Dados).

Porém, como serão apresentados todos os recursos do software, seguem abaixo os tipos de dados que serão utilizados nesta Unidade Curricular:

DADOS NUMÉRICOS: podem ser números inteiros ou com ponto flutuante (valores monetários, com casas decimais):

INTEGER - por default até 38 dígitos;

NUMBER(tamanho) - delimitação do tamanho do atributo;

NUMBER(precisão, escala): onde precisão é a parte inteira e tem o total do atributo, e, deste total, a escala é a quantidade de casas decimais.

DATA: século, ano, mês, dia, hora, minuto e segundo. OBS.: este campo aceita de 1º de janeiro de 4712 a.C. a 31 de dezembro de 9999 d.C.

DATE - o formato vai de acordo com a linguagem instalada. Por exemplo: se for em português, será DIA/MÊS/ANO, sendo que o ano terá quatro dígitos.

DADOS ALFANUMÉRICOS: aceita letras, números, espaço em branco, símbolos (!, @, #, $, %, *, (, ), entre outros):

CHAR(tamanho): tamanho fixo. Aceita até 2000 bytes (caracteres);

VARCHAR(tamanho): tamanho variável. Aceita até 4000 bytes (caracteres).

OBS.: Os nomes das entidades e dos atributos devem seguir as seguintes regras e não fazem distinção entre letras maiúsculas ou minúsculas (não é CASE-SENSITIVE):

iniciar com uma letra;

ter de 1 a 30 caracteres;

somente A-Z, a-z, 0-9, _, $ e #;

não deve duplicar o nome de outra coluna, entidade ou relacionamento;

não deve ser uma palavra reservada (comando) da linguagem SQL.

OBSERVAÇÃO: Os nomes não fazem distinção entre maiúsculas de minúsculas.

Confira o vídeo a seguir, para reforçar seu conheciento sobre Software BrModelo.

Seite 8

MODELO LÓGICO DE DADOS

Modelo Lógico de Dados

Vamos iniciar a jornada desta unidade, conferindo o quadrinho a seguir!

Quadrinho

Como você deve ter percebido pela história acima, nesta unidade de ensino veremos o Modelo Lógico de Dados adequado ao Modelo Relacional de Dados, que tem o objetivo de relacionar as entidades com seus atributos de chave primária e chave estrangeira nos relacionamentos entre essas entidades.

Ao final deste conteúdo, você será capaz de:

Elaborar modelos lógicos de dados.

Descrever modelos lógicos de dados.

Aplicar normalização a um modelo de dados.

Bons estudos!

Introdução ao modelo lógico de dados

O projeto lógico consta da transformação de um modelo ER em um modelo lógico, que implementa, em nível de SGBD relacional, os dados representados abstratamente no modelo ER. O termo “implementação” significa que ocorre uma transformação de um modelo mais abstrato para um modelo que contém mais detalhes de implementação (HEUSER, 2011).

O modelo lógico de dados reflete as propriedades necessárias para a tradução do modelo conceitual, de maneira que seja possível a descrição dos elementos capazes de serem interpretados por SGBD, tais como o detalhamento dos atributos, chaves de acesso, integridade referencial e normalização.

Na etapa de desenvolvimento do modelo lógico de dados, devem ser considerados os aspectos relacionados ao tipo de banco de dados a serem utilizados (rede, hierárquico, relacional ou orientado a objetos) (PUGA; FRANÇA; GOYA, 2013).

Notação engenharia de informações

A notação Engenharia de Informações foi definida por James Martin nos anos 1980. A notação que recebe o seu nome foi criada a partir de estudos sobre engenharia de informação, nos quais enfatizava a importância dos modelos de dados em sistemas de informações. Essa notação é bastante difundida na área de desenvolvimento de sistemas e existem diversas ferramentas para elaboração de modelos relacionais que adotam essa notação (PUGA; FRANÇA; GOYA, 2013).

Essa notação é usada até hoje em diversas ferramentas CASE para a modelagem de dados e possui as seguintes características:

Atributos somente aparecem em entidades (jamais em relacionamentos);

Denominação de um relacionamento é escrita em forma de verbos. Usamos a voz ativa e a voz passiva quando se fazem necessárias duas denominações dependendo da ferramenta. Exemplo: contém e está_contido;

Notação das cardinalidades é gráfica (o mais próximo do retângulo representa a cardinalidade máxima);

Relacionamentos binários.

Componentes da engenharia da informação

A seguir serão apresentados os componentes que fazem parte da notação da engenharia de informação: ENTIDADE, ATRIBUTOS, TUPLAS e RELACIONAMENTOS.

Entidade

A ENTIDADE é uma coisa ou objeto, concreto ou abstrato, no mundo real com uma existência independente. Uma entidade pode ser um objeto com uma existência física (por exemplo: casa, funcionário) ou pode ser um objeto de existência conceitual (por exemplo: cargo, curso) (ELMASRI; NAVATHE, 2018).

A classificação das entidades em tipos tem como função facilitar o entendimento MER, permitindo identificar impactos quando há necessidade de modificação no modelo. Características dos tipos de entidades: primária (forte), dependente (fraca) e associativa.

O quadro a seguir, apresenta os tipos de entidades: PRIMÁRIA ou FORTE, DEPENDENTE ou FRACA, ASSOCIATIVA e CATEGORIA.

QUADRO 1 | TIPOS DE ENTIDADES

TIPO DE ENTIDADEDESCRIÇÃO

PRIMÁRIA ou FORTEQuando não tem dependência com nenhum outro para formar seu conceito. Esse tipo de entidade contém dados que são fundamentais para manter uma organização.

DEPENDENTE OU FRACA

Ocorre quando ela não existe por si só e sua existência no MER está condicionada a outra única entidade, da qual ela depende.

ASSOCIATIVAA entidade é associativa quando ela não existe no MER por si só, e sua existência está condicionada a existência de duas ou mais entidades.

CATEGORIAQuando superclasse (entidade principal) e subclasse se relacionam. A esse caso aplica-se o conceito de generalização/especialização.

INSTITUCIONAL, 2022.

Atenção!

NOME DAS ENTIDADES

Uma boa prática é colocar os nomes das entidades com todas as letras maiúsculas, nomes formados só por substantivos, sem preposição e conjunções, nome no singular, sem cedilha, sem acento e palavras compostas separadas por underline, com nomes até 30 caracteres. Ex.: ALUNO, HISTORICO_ESCOLAR.

Para mais informações sobre nomenclatura de padronização das entidades, leia o Saiba Mais:

Saiba mais

Modelagem de Dados - Padronização de Nomenclatura

Artigo disponível na revista eletrônica SQL Magazine volume 100 da Devmedia.

https://www.devmedia.com.br/padronizacao-de-nomenclatura-revista-sql-magazine-100/24710

Atributo

Entidades possuem ATRIBUTOS que são propriedades específicas que as descrevem. Exemplo: salário do funcionário, nome do aluno. Uma entidade em particular terá um valor para cada um dos seus atributos. O atributo é como um campo e é identificado por um nome de campo (ELMASRI; NAVATHE, 2018).

Atenção!

NOME DOS ATRIBUTOS

Uma boa prática é colocar os nomes dos atributos com todas as letras minúsculas, no singular, sem cedilha, sem acento e palavras compostas separadas por underline, com nomes até 30 caracteres. Ex.: data_nascimento_aluno, salario_bruto_empregado.

Independência dos dados

O atributo (ou dado) é o elemento mais estável de um sistema de informação. O valor, o conteúdo do atributo altera-se, mas o atributo dificilmente sofre mudanças. Porém, o processo que, por exemplo, calcular o valor do salário líquido do funcionário pode sofrer modificações devido a uma alteração da lei do governo. Ou seja, há interatividade entre o atributo e o processo, mas são independentes (HEUSER, 2011).

Independência de (aplicações em relação aos) dados significa que uma alteração no modelo lógico de dados afeta “pouco” as aplicações.

A seguir uma dica importante a respeito da independência dos dados:

LEMBRE-SE DE QUE NA CONSTRUÇÃO DO BANCO DE DADOS A PRIMEIRA REGRA É:

O DADO É INDEPENDENTE DO PROCESSO!

Ou seja, não devemos projetar o banco de dados pensando na linguagem de programação (processo) que irá acessar, pois, ele deve ser construído de uma forma que possa ser acessado por qualquer linguagem de programação que há no momento e nas próximas que virão, pois, armazenamos no banco de dados os dados históricos.

Classificação dos atributos

Há três tipos de atributos, conforme apresentado no quadro a seguir.

QUADRO 2 | CLASSIFICAÇÃO DOS ATRIBUTOS

TIPO DE ATRIBUTODESCRIÇÃOEXEMPLO

ATRIBUTO NATURALDescreve a entidade e sua existência independente da forma como será utilizado pelo sistema. É o mais adequado para ser atributo identificador.nome_cliente

ATRIBUTO CALCULADO (DERIVADO)Criado por causa de uma necessidade específica do sistema. Formado por um processo que utiliza os dados naturais (e por isso também é chamado de derivado).salario_bruto_empregado

ATRIBUTO ARTIFICIALCriado para possibilitar uma identificação na entidade. Surge na etapa do desenvolvimento do sistema, quando não se encontra entre os dados naturais um que possa ser usado como atributo identificador.codigo_cliente

INSTITUCIONAL, 2022.

No curso DataBase Foundations temos mais informações sobre Entidades e Atributos.

Saiba mais

ORACLE ACADEMY

DataBase Foundations - capítulo Entidades e Atributos.

Abrir pdf

Atributo de identificação

O conceito básico para identificar linhas e estabelecer relações entre linhas de tabelas de um banco de dados relacional é o de chave. Em um banco de dados relacional, há ao menos três tipos de chaves a considerar: a chave primária, a chave alternativa e a chave estrangeira. Uma chave primária é uma coluna ou uma combinação de colunas cujos valores distinguem uma linha das demais dentro de uma tabela (ELMASRI; NAVATHE, 2018).

Ou seja, tem a função de identificar, de modo claro, cada ocorrência de uma entidade. Caso não seja possível um único atributo garantir a identificação à ocorrência, podem-se incluir outros atributos para compô-la.

O quadro a seguir, apresenta os tipos de atributos que podem identificar como única uma tupla:

QUADRO 3 | TIPOS DE ATRIBUTOS IDENTIFICADORES

TIPO DE ATRIBUTO IDENTIFICADORDESCRIÇÃO

CHAVE PRIMÁRIAformada por um ou mais atributos com objetivo de dar unicidade às ocorrências de uma entidade. Obs.: Quando formada por mais de um atributo também é chamada de chave composta ou concatenada.

CHAVE SECUNDÁRIAFormada por um ou mais atributos, que facilitam o acesso aos dados. Considerados índices, formam meios de classificação e pesquisa para as ocorrências.

CHAVE CANDIDATAComposta por um ou mais atributos da entidade, uma vez que possui conteúdos únicos, os quais se repetem em diferentes ocorrências, sendo candidata a chave primária.

CHAVE ALTERNATIVASão as chaves candidatas, que não foram utilizadas como chave primária.

SUPER CHAVEAtributo ou combinação de atributos que identifica exclusivamente cada tupla da entidade.

ELMASRI; NAVATHE, 2018 [ADAPTADA].

Atenção!

Chave Composta

Também chamada de chave concatenada, é formada por dois ou mais atributos que em conjunto identificam uma tupla como única, representando uma chave primária.

No curso DataBase Foundations temos mais informações sobre identificadores.

Saiba mais

DataBase Foundations - capítulo Identificador Exclusivo.

Abrir pdf

Nomenclatura para padronização dos atributos

Para padronizar o nome dos atributos, usamos os mnemônicos conforme o quadro a seguir.

QUADRO 4 | MNEMÔNICOS PARA NOMEAÇÃO DOS ATRIBUTOS

MNEMÔNICODESCRIÇÃOOBS.EXEMPLO

cdcódigochave primária ou compostacd_registro_academico_aluno

sgsiglachave primária ou compostasg_curso

dtdatachave compostadt_nascimento_funcionario

hrhorachave compostahr_inicio_sessao_filme

nmnome nm_professor

dsdescrição ds_produto

qtquantidade qt_idade_aluno

vlvalor monetário vl_mercadoria

pcpercentual (%) pc_desconto_produto

imimagem im_filme

icindicador de conteúdo (booleano) ic_credito_debito

dddia da semana (segunda-feira) ou número do dia do mês (14) dd_aula_unidade_curricular

mmmês (abreviado com dois dígitos, três letras ou por extenso) mm_reajuste_salarial

aaano aa_conclusao_curso

INSTITUCIONAL, 2022.

Para mais informações sobre nomenclatura de padronização dos atributos, leia o Saiba Mais:

Saiba mais

Modelagem de Dados - Padrão de nomenclatura de banco de dados

Artigo disponível na revista eletrônica SQL Magazine volume 54 da Devmedia.

https://www.devmedia.com.br/artigo-sql-magazine-54-projeto-sql-magazine/9394

Tupla

Entidade é um conjunto não ordenado de linhas (tuplas ou instâncias na terminologia acadêmica) (ELMASRI; NAVATHE, 2018).

Atenção!

As tuplas ou instâncias são linhas das entidades (registros das tabelas) e fazem distinção entre letras maiúsculas e minúsculas (CASE SENSITIVE).

A seguir, um exemplo de ENTIDADE, ATRIBUTO e TUPLA:

Exemplo

PRODUTO<= Entidade

cd_produtonm_produto<= Atributo

1001Borracha<= Tupla

1002Caderno

Relacionamento

O relacionamento estabelece uma relação ou associação entre as entidades, sendo representado por uma linha contínua, que liga as entidades. Um relacionamento possui dois sentidos: ida e volta. Cada um deles possui um nome próprio, sendo que o de ida deve ser em voz ativa, e o de volta, em voz passiva (ELMASRI; NAVATHE (2018).

Os relacionamentos são classificados como consta no quadro a seguir (ELMASRI; NAVATHE, 2018; PUGA; FRANÇA; GOYA, 2013):

QUADRO 5 | CLASSIFICAÇÃO DOS RELACIONAMENTOS

TIPO DE RELACIONAMENTODESCRIÇÃO

RELAÇÃO SIMÉTRICA (N : N)Situação em que a ocorrência da entidade A possui um relacionamento com várias ocorrências da entidade B, e uma ocorrência da entidade B também possui relacionamento com várias ocorrências da entidade A. Pode-se considerar que as entidades A e B mantêm, entre elas, proporções simétricas.

RELAÇÃO RECURSIVA (1:N ou N:N)

Também conhecida como autorrelacionamento, situação em que uma ocorrência da entidade A possui um relacionamento com várias ocorrências da própria entidade A. Pode-se considerar que a entidade A mantém um autorrelacionamento, ou seja, a entidade se relaciona com ela mesma.

RELACIONAMENTO CONDICIONAL

Refere-se a relacionamento em que nem todas as ocorrências de uma entidade estão relacionadas às ocorrências de outra entidade. Pode-se considerar que, quando o relacionamento tem um lado opcional, as ocorrências das entidades que participam do relacionamento são independentes umas das outras.

RELACIONAMENTO NORMALÉ quando duas entidades que são independentes se relacionam, ou seja, um relacionamento entre duas entidades fortes.

ELMASRI; NAVATHE, 2018 [ADAPTADA].

Grau do relacionamento

É possível classificar o relacionamento pelo grau de um relacionamento que é definido pela quantidade de entidades que participam do relacionamento: GRAU 1, GRAU 2, GRAU 3 e GRAU 4.

Recurso lista interativa:

GRAU 1

GRAU 2

GRAU 3

GRAU 4

Conteúdo

GRAU 1:

Relacionamento estabelecido somente com uma entidade. Relação recursiva ou de autorrelacionamento;

Voltar para a navegação do recurso lista interativa

Para aprofundar seu conhecimento, confira a leitura indicada a seguir.

Estudo Guiado

Capítulo 4 - Modelagem de dados - Leia as páginas 83 a 108.

Clique no link e leia o livro

PUGA, S.; FRANÇA, E.; GOYA, M. Banco de Dados: Implementação em SQL, PL/SQL e Oracle 11G. São Paulo: Pearson, 2013.

Cardinalidade

A cardinalidade é a quantificação de um relacionamento determinada com base nas regras de negócio, mostrando, em termos quantitativos, como os dados são associados uns aos outros. Ademais, a cardinalidade estabelece o relacionamento entre a quantidade de ocorrências de uma entidade e a quantidade de ocorrências de outra entidade (PUGA; FRANÇA; GOYA, 2013).

A Figura a seguir, mostra os tipos de combinações das cardinalidades entre duas entidades (relacionamento bidirecional):

FIGURA 1 | TIPOS DE CARDINALIDADES

A Figura a seguir, mostra a representação da leitura entre as cardinalidades mínima (0 ou 1) e máxima (1 ou vários (N)):

FIGURA 2 | CARDINALIDADE MÍNIMA E MÁXIMA

Dicionário de Dados

O desenvolvimento do sistema inicia-se na fase de análise do ciclo de vida do sistema com a prospecção do dicionário de dados que atravessa a fronteira sistema/ambiente. O dicionário de dados é o caminho dos dados de um ponto a outro no sistema. Tem a função de transferir os dados entre os diversos processos. É formado por diversos dados que são denominados de ELEMENTOS DE DADOS.

Para direcionar a definição das estruturas de dados deve ser considerado o documento do dicionário de dados (DD). O Dicionário de Dados (DD) armazena a descrição detalhada das entidades e atributos de um projeto de banco de dados, ou seja, contém os metadados do projeto. Metadado é a informação sobre o dado (atributo) armazenado (PUGA; FRANÇA; GOYA, 2013).

Um dicionário de dados (data dictionary) é uma coleção de metadados que contém definições e representações de elementos de dados. Dentro do contexto de SGBD, um dicionário de dados é um grupo de tabelas habilitadas apenas para leitura ou consulta, ou seja, é uma base de dados propriamente dita que, entre outras coisas, mantém as seguintes informações: definição precisa sobre elementos de dados; perfis de usuários, papéis e privilégios; descrição de objetos e restrições de integridade (WIKIPÉDIA, 2020a).

O dicionário de dados é criado no sentido em que os elementos aparecem em um protótipo que pode ser uma página na Web, um relatório ou uma tela de um sistema. Não possui restrição tecnológica e na maioria das vezes será uma entidade no projeto de banco de dados.

No quadro a seguir, são apresentados os elementos da notação do dicionário de dados:

QUADRO 6 | NOMENCLATURA DO DICIONÁRIO DE DADOS

NOTAÇÃODESCRIÇÃO

=Dicionário de dados é composto de (um conjunto de elementos de dados).

( )Opcional (atributo que não é obrigatório o preenchimento).

[ / ]Ou (será preenchido um atributo ou outro atributo).

{ }Múltiplas ocorrências (1 a várias ocorrências). Quando o mesmo atributo aparece n vezes com tuplas diferentes.

@Indica que o elemento de dado é um atributo chave (caso não esteja no protótipo não precisa acrescentar).

+e (concatenação, representa a união a partir do segundo elemento de dado).

< / >e/ou, ocorre somente nenhum, um ou ambos os atributos preenchidos.

WIKIPÉDIA, 2020 [ADAPTADA].

Atenção!

Para nomear o dicionário de dados não usamos plural, preposições, conjunções, acento, cedilha, palavras separadas com underline (_) e evita-se a restrição tecnológica.

Relacionamentos de acordo com as cardinalidades

Os tipos de relacionamentos de acordo com a cardinalidade máxima são: relacionamento 1 : 1, relacionamento 1 : N, relacionamento autorrecursivo e relacionamento N : N.

Relacionamento 1:1

No relacionamento máximo 1:1 (lê-se um-para-um) a cardinalidade mínima pode ser zero ou um.

Os relacionamentos entre as entidades são criados em função do ciclo de negócio que o modelo de dados retrata. Dois sistemas que retratam ciclos de negócios diferentes podem ter diversos objetos iguais na base de dados, mas os relacionamentos irão dar significados diferentes para cada modelo conforme o ciclo imponha. Durante a construção do modelo, para testar sua consistência, é efetuada a NAVEGAÇÃO ENTRE AS ENTIDADES, que será a mesma que os processos realizarão para produzir diversas respostas que o sistema necessita fornecer ao ambiente. Na descrição e detalhamento dos processos, as sequências de acessos aos objetos ocorrerão através dos relacionamentos.

Um relacionamento 1: 1 existe entre duas entidades, quando uma única tupla (registro) da primeira entidade está relacionada a uma única tupla da segunda entidade e uma única tupla da segunda entidade está relacionada a uma única tupla da primeira entidade.

Esse tipo de grau de relacionamento é bastante restritivo na associação dos elementos e, por isso, acaba sendo pouco comum no dia a dia.

Os relacionamentos de grau 1:1 são bastante difíceis de serem caracterizados, pois qualquer mudança de interpretação ou visão pode fazer com que facilmente eles sejam questionados e até reconsiderados.

Atenção!

No Relacionamento do tipo 1 : 1 quem determina qual é a entidade forte (pai) é o administrador de dados e então a chave primária (primary key - PK) dessa entidade é copiada para a entidade fraca (filho) como atributo estrangeiro (foreign key - FK).

O exemplo apresentado na Figura a seguir, diz que:

uma CONFERENCIA tem uma COMISSAO;

uma COMISSAO tem uma CONFERENCIA.

FIGURA 3 | EXEMPLO RELACIONAMENTO 1 : 1

Relacionamento 1:N

No relacionamento máximo 1 : N a cardinalidade mínima pode ser zero ou um.

Todo relacionamento do tipo 1: N gera um atributo estrangeiro (foreign key - FK) que é o elo de ligação entre duas instâncias, e a existência de um atributo estrangeiro indica que há um relacionamento da tupla de uma entidade com outra tupla de outra entidade, ou de maneira simples, indica que há um relacionamento entre duas entidades. No relacionamento entre duas entidades, a entidade dependente herda a chave do objeto de origem como atributo estrangeiro.

Atenção!

O atributo estrangeiro aparece em todos os relacionamentos do tipo 1 : N independentemente da cardinalidade mínima dos relacionamentos. O objeto associado à cardinalidade N recebe como atributo estrangeiro a chave do objeto associado à cardinalidade 1.

O atributo estrangeiro poderá ou não vir a ser chave do objeto dependente, isso depende da conveniência na identificação dos objetos. Chave estrangeira é o nome dado ao atributo estrangeiro quando o mesmo é chave do objeto dependente.

O exemplo apresentado na Figura a seguir, diz que:

um PROPRIETARIO possui um ou vários VEICULOS;

um VEICULO é possuído por um PROPRIETARIO por vez.

FIGURA 4 | EXEMPLO RELACIONAMENTO 1 : N

Relacionamento autorrecursivo

No relacionamento recursivo ou autorrelacionamento a cardinalidade mínima pode ser zero ou um.

Em algumas situações específicas do ciclo de negócio, temos uma entidade que se relacione com ela mesma. Esse tipo de relacionamento é chamado de self-relation (autorrelacionamento, relacionamento unário ou relacionamento recursivo). Por exemplo: plano de contas de um sistema contábil e organograma.

As duas entidades que se relacionam dessa maneira são a mesma, portanto têm os mesmos atributos primários. O uso mais comum desse tipo de estrutura ocorre quando se deseja retratar uma hierarquia.

Nesse caso o relacionamento entre os objetos têm cardinalidade 1 : ( N ). As cardinalidades mínimas iguais a zero indicam que o primeiro objeto da hierarquia não se relaciona com nenhum objeto no nível superior, assim como o objeto que retrata o nível hierárquico mais baixo também não se relaciona com nenhum outro objeto no nível inferior.

Atenção!

O relacionamento recursivo permite criar flexibilidade no modelo de dados, já que com o passar do tempo, o ciclo de negócios pode exigir alterações no sentido de ampliar ou diminuir os níveis de hierarquia estabelecida. Desta forma o modelo de dados não sofrerá nenhum impacto quando ocorrer uma eventual alteração.

O exemplo apresentado na Figura a seguir, diz que:

um FUNCIONARIO PODE (cardinalidade mínima 0) gerenciar nenhum ou vários FUNCIONARIOS;

um ou vários FUNCIONARIOS são gerenciados por um FUNCIONARIO.

FIGURA 5 | EXEMPLO RELACIONAMENTO RECURSIVO

Relacionamento N:N

No relacionamento máximo N:N (lê-se vários para vários) a cardinalidade mínima pode ser zero ou um. Obs.: algumas ferramentas CASE classificam como relacionamentos M : N.

As entidades também podem se relacionar com cardinalidade M:N. E esta cardinalidade não gera atributos ou chaves estrangeiras. Mas, independentemente da cardinalidade, havendo relacionamento, é necessário haver a navegação entre as entidades e assim é criada uma nova entidade chamada ENTIDADE DE RESOLUÇÃO ou OBJETO DE RESOLUÇÃO, nome dado à entidade associativa que surge no relacionamento N : N. A chave dessa “nova” entidade é formada pelos atributos estrangeiros que são chave nas entidades de origem.

O exemplo apresentado na Figura a seguir, diz que:

um MEDICO atende um ou vários PACIENTES;

um ou vários PACIENTES são atendidos por um ou vários MÉDICOS.

FIGURA 6 | EXEMPLO RELACIONAMENTO N : N

Mecanismos de movimentação das cardialidades

O mecanismo de movimentação das cardinalidades entre as entidades fortes (entidade pai) se movimentam para resolver o relacionamento do tipo M : N, garantindo assim, o sentido da leitura do relacionamento. As cardinalidades das entidades-pai passam a ter cardinalidade mínima e máxima de 1 apresentado na Figura a seguir:

FIGURA 7 | MECANISMO DE NAVEGAÇÃO PARA RESOLUÇÃO DO RELACIONAMENTO N : N

Então o relacionamento se tornará um relacionamento de 1 para N onde no meio há uma entidade chamada ENTIDADE DE RESOLUÇÃO ASSOCIATIVA que é formada pela chave primária composta estrangeira ou chave primária concatenada estrangeira. A Figura 9 mostra a entidade criada que pode ter os nomes MEDICO_PACIENTE ou ter um nome próprio como ATENDIMENTO ou CONSULTA, apresentado na Figura a seguir:

FIGURA 8 | EXEMPLO RESOLUÇÃO RELACIONAMENTO N : N

Atenção!

ENTIDADE OU OBJETO DE RESOLUÇÃO

Toda entidade de resolução é chamada de ASSOCIATIVA, quando formada somente pela chave composta estrangeira ou chave concatenada estrangeira.

Mas, se esta entidade tiver atributos não chave próprios é chamada de ENTIDADE ATRIBUTIVA.

A seguir, temos um vídeo que ensina os quatro tipos de relacionamento:

Videoaula

No curso DataBase Foundations temos mais informações sobre Relacionamentos.

Saiba mais

DataBase Foundations - capítulo Relacionamentos.

DataBase Foundations - capítulo Mais Sobre Relacionamentos.

DataBase Foundations - capítulo Rastreando Alterações de Dados.

Abrir pdf

Normalização

O conceito de normalização foi introduzido em 1972 por Edgard Frank Codd. Consiste em um processo matemático formal com fundamento na teoria dos conjuntos. A normalização aplica um conjunto de regras sobre as entidades de um projeto de banco de dados para verificar se estas foram corretamente projetadas.

Há dois níveis em que podemos discutir a adequação de esquema de relação. O primeiro é o nível lógico ou conceitual, que é a forma como os usuários interpretam os esquemas de relação (tanto básica como virtual (visões)) e o significado de seus atributos. Já o segundo é o nível de implementação ou armazenamento físico, como as tuplas em uma relação básica são armazenadas e atualizadas (ELMASRI; NAVATHE, 2018).

A normalização é um procedimento que examina os atributos de uma entidade com o objetivo de evitar anomalias que possam ocorrer na inclusão, na exclusão ou na alteração de uma ocorrência específica em uma entidade. Esse procedimento procura simplificar os atributos nas respectivas ocorrências, eliminando grupos repetitivos, dependência parcial da chave primária, dependências transitivas, dados redundantes e dependência de atributos multivalorados, contribuindo para a estabilização do modelo de dados e para a redução de manutenções. A normalização é baseada em relações matemáticas (teoria de conjuntos) e tem como objetivo estruturar as relações entre as entidades, garantindo que não existam anomalias ou redundâncias no armazenamento de dados. As anomalias ocorrem durante o processo de manipulação dos dados e se tornam severas durante as operações de inclusão, alteração e exclusão de dados (PUGA; FRANÇA; GOYA, 2013).

É através da normalização, onde é obtido um modelo relacional, que temos as descrições das entidades correspondentes ao projeto de banco de dados (HEUSER, 2011).

Recurso lista interativa:

Os objetivos do processo de normalização são:

Conteúdo

Os objetivos do processo de normalização são::

Garantir a integridade dos dados;

Organizar e dividir as tabelas de maneira eficiente, diminuindo ou eliminando a redundância de dados;

Eliminar estruturas inexistentes (atributos multivalorados);

Possibilitar entidades flexíveis e de fácil manutenção.

Voltar para a navegação do recurso lista interativa

Uma vez normalizados todos os arquivos do sistema, os diferentes esquemas relacionais obtidos pela normalização são integrados, gerando o esquema relacional do banco de dados do sistema. Nessa etapa, as informações comuns a diferentes arquivos são identificadas e representadas uma única vez. Esse processo baseia-se no conceito de forma normal (HEUSER, 2011).

As regras de normalização são aplicadas durante o transcorrer de toda a construção do modelo de dados. Devem ser aplicadas quantas vezes for necessário para que se obtenha um modelo estável (nome dado a um modelo normalizado, que esteja atendendo às Formas Normais).

As Formas Normais são aplicadas em sequência, sempre verificando a situação do conjunto de dados com relação à Primeira Forma Normal (1FN), depois com relação à Segunda Forma Normal (2FN), depois com relação à Terceira Forma Normal (3FN) e assim sucessivamente. A cada revisão que se faça, inicia-se novamente pela 1FN, depois a 2FN e assim por diante.

Forma Normal

A Forma Normal (FN) é uma regra que deve ser obedecida por uma entidade para que esta seja considerada “bem projetada”.

Há diversas formas normais, isto é, diversas regras, cada vez mais rígidas, para verificar entidades relacionais. Vamos considerar as três formas normais, denominadas simplesmente primeira, segunda e terceira, abreviadamente 1FN, 2FN e 3FN, por ser as regras aplicadas em todos os projetos de banco de dados com o objetivo de eliminar a redundância de dados.

LEMBRE-SE DE QUE NA CONSTRUÇÃO DO BANCO DE DADOS A SEGUNDA REGRA É:

NÃO DEVE CONTER REDUNDÂNCIA DE DADOS

O projeto de banco de dados deve ser construído de uma forma que, além de ser independente do banco de dados do processo (linguagem de programação), conforme vimos anteriormente, também não deve conter redundância de dados.

1ª Forma Normal (1FN)

Diz-se que uma tabela está na primeira forma normal (1FN) quando ela não contém tabelas aninhadas (HEUSER, 2011).

Atenção!

DEPENDÊNCIA FUNCIONAL

O relacionamento entre dois ou mais atributos de forma que o valor de um atributo identifique o valor para cada um dos outros atributos, ou seja, um atributo está relacionado a outro. Sempre que um atributo X identificar um atributo Y (X a Y), dizemos que há uma dependência funcional, ou seja, X é o DETERMINANTE e Y é o DEPENDENTE.

Dependência Funcional

Para entender as duas formas normais que serão apresentadas a seguir é necessário compreender o conceito de dependência funcional.

Uma dependência funcional é uma restrição de integridade, ou seja, ela deve ser obedecida por todos os estados do banco de dados. Assim, para determinar uma dependência funcional, não basta observar o estado atual do banco de dados. É necessário conhecer as regras de construção desse banco de dados (HEUSER, 2011).

2ª Forma Normal (2NF)

A segunda forma normal (2 FN) explica que uma entidade encontra-se na segunda forma normal quando, além de estar na 1FN, não contém dependências parciais da chave primária.

Atenção!

Dependência Parcial é uma dependência (funcional) parcial que ocorre quando um atributo depende apenas de parte de uma chave primária composta ou concatenada.

A passagem à segunda forma normal (2FN) elimina um certo tipo de redundância de dados. Uma tabela encontra-se na segunda forma normal (2FN) quando, além de encontrar-se na primeira forma normal, cada atributo não chave depende da chave primária completa. Uma entidade que não se encontra na segunda forma normal contém dependências funcionais parciais, ou seja, contém atributos não chave que dependem apenas de uma parte da chave primária (HEUSER, 2011).

Uma entidade que atende a 1FN e que possui apenas uma coluna como chave primária não contém dependências parciais, já que, nesta entidade , é impossível um atributo depender de uma parte da chave primária, visto que a chave primária não é composta por partes (por diversas colunas). Assim, toda entidade que está na 1FN e que possui apenas um atributo como chave primária já está na 2FN. O mesmo aplica-se para uma entidade que contenha apenas atributos chave primária.

3ª Forma Normal (3FN)

A terceira forma normal (3 FN) diz que uma entidade encontra-se na terceira forma normal quando, além de estar na 2FN, não contém dependências transitivas da chave primária ou composta (concatenada).

À terceira forma normal, elimina-se outro tipo de redundância de dados.

Uma entidade encontra-se na 3FN quando, além de estar na 2FN, todo atributo não chave depende diretamente da chave primária, isto é, quando não há dependências funcionais transitivas ou indiretas (HEUSER, 2011).

Uma dependência funcional transitiva ou indireta acontece quando uma coluna não chave primária depende funcionalmente de outra coluna ou combinação de colunas não chave primária.

Atenção!

A dependência funcional transitiva ocorre quando um atributo, além de depender da chave primária da entidade, depende de outro atributo ou conjunto de atributos da entidade. A passagem à 3FN consiste em separar as entidades, de forma a eliminar as dependência transitivas.

Para a maioria dos documentos e arquivos, a decomposição até a 3FN é suficiente para obter o esquema de um banco de dados correspondente ao documento. Na literatura, aparecem outras formas normais, como a forma normal de Boyce/Codd, a 4FN e a 5FN.

Para aprofundar seu conhecimento, confira a leitura indicada a seguir.

Estudo Guiado

Capítulo 14 - Fundamentos de Dependências Funcionais e Normalização para bancos de dados relacionais. Leia as páginas 415 a 454.

Clique no link e leia o livro

ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 7. ed. São Paulo: Pearson, 2018.

No curso DataBase Foundations temos mais informações sobre Normalização.

Saiba mais

DataBase Foundations - capítulo Normalização

Abrir pdf

Para aprofundar seu conhecimento, confira a leitura indicada a seguir.

Estudo Guiado

Capítulo 5 - Normalização. Leia as páginas 117 a 143.

Clique no link e leia o livro

PUGA, S.; FRANÇA, E.; GOYA, M. Banco de Dados: Implementação em SQL, PL/SQL e Oracle 11G. São Paulo: Pearson, 2013.

A seguir, Estudo de Caso com aplicação da Normalização sobre uma ordem de compra:

Estudo de caso

Videoaula

Oracle SQL Developer Data Modeler

Oracle SQL Developer Data Modeler é uma ferramenta gráfica gratuita que aprimora a produtividade e simplifica as tarefas de modelagem de dados. Com o Oracle SQL Developer Data Modeler, os usuários podem criar, navegar e editar modelos lógicos, relacionais, físicos, multidimensionais e de tipo de dados. O Data Modeler fornece recursos de engenharia direta e reversa e oferece suporte ao desenvolvimento colaborativo por meio do controle integrado de código-fonte. O Data Modeler pode ser usado em ambientes tradicionais e de nuvem (ORACLE, 2020).

FIGURA 9 | TELA PRINCIPAL ORACLE SQL DEVELOPER DATA MODELER

Atenção!

Mas como serão apresentados todos os recursos do software, seguem abaixo os tipos de dados que serão utilizados nesta Unidade Curricular:

DADOS NUMÉRICOS: podem ser números inteiros ou com ponto flutuante (valores monetários, com casas decimais):

INTEGER - por default até 38 dígitos;

SMALLINT - mesma função que o INTEGER entretanto ocupa menos espaço para armazenamento dos dados;

NUMBER(tamanho) - delimitação do tamanho do atributo;

NUMBER(precisão, escala): onde precisão é a parte inteira e tem o total do atributo e deste total, a escala é a quantidade de casas decimais.

DATA: século, ano, mês, dia, hora, minuto e segundo. Obs. este campo aceita de 1º de janeiro de de 4712 a.C. a 31 de dezembro de 9999 d.C.

DATE - o formato vai de acordo com a linguagem instalada. Por exemplo, se for em português será DIA/MÊS/ANO, sendo que o ano terá quatro dígitos.

DADOS ALFANUMÉRICOS: aceita letras, números, espaço em branco, símbolos (!, @, #, $, %, *, (, ), entre outros) :

CHAR(tamanho): tamanho fixo. Aceita até 2000 bytes (caracteres);

VARCHAR(tamanho): tamanho variável. Aceita até 4000 bytes (caracteres).

OBS.: Os nomes das entidades e dos atributos devem seguir as seguintes regras e não fazem distinção entre letras maiúsculas ou minúsculas (não é CASE-SENSITIVE):

iniciar com uma letra;

ter de 1 a 30 caracteres;

somente A-Z, a-z, 0-9, _, $ e #;

não deve duplicar o nome de outra coluna, entidade ou relacionamento;

não deve ser uma palavra reservada (comando) da linguagem SQL. OBSERVAÇÃO: Os nomes não fazem distinção entre maiúsculas de minúsculas.

A seguir são apresentados as instruções do software Oracle SQL Developer Data Modeler:

FIGURA 10 | BARRAS DE OPÇÕES - MODELO LÓGICO

FIGURA 11 | ENGENHARIA REVERSA PARA MODELO RACIONAL

FIGURA 12 | BARRA DE OPÇÕES - MODELO RACIONAL

FIGURA 13 | ORACLO SQL DEVELOPER DATA MODELER

FIGURA 14 | ASSISTENTE DE IMPORTAÇÃO DE DICIONÁRIO DE DADOS

FIGURA 15 | MENU ARQUIVO - OPÇÃO DICIONÁRIO DE DADOS >CONEXÃO DE BANCO DE DADOS

FIGURA 16 | MENU ARQUIVO - DICIONÁRIO DE DADOS - IMPORTAÇÃO DE DICIONÁRIO DE DADOS PASSO 1

FIGURA 17 | MENU ARQUIVO - DICIONÁRIO DE DADOS - IMPORTAÇÃO DE DICIONÁRIO DE DADOS PASSO 2

FIGURA 18 | MENU ARQUIVO - DICIONÁRIO DE DADOS - IMPORTAÇÃO DE DICIONÁRIO DE DADOS PASSO 3

FIGURA 19 | MENU ARQUIVO - DICIONÁRIO DE DADOS - IMPORTAÇÃO DE DICIONÁRIO DE DADOS PASSO 4

FIGURA 20 | MENU ARQUIVO - DICIONÁRIO DE DADOS - IMPORTAÇÃO DE DICIONÁRIO DE DADOS PASSO 5

FIGURA 21 | ORACLE SQL DEVELOPER DATA MODELER

FIGURA 22 | PROPRIEDADES DA ENTIDADE - ENTITY_3

FIGURA 23 | PROPRIEDADES DA ENTIDADE - ENTITY_3

No curso DataBase Foundations temos mais informações sobre Oracle SQL Developer Data Modeler.

Saiba mais

DataBase Foundations - capítulo Oracle SQL Developer Data Modeler.

Abrir pdf

O Estudo de Caso a seguir será usado para aprender a user o SQL Developer Oracle Data Modeler:

Estudo de caso

Um escritório de despachante precisa cadastrar os seus clientes e seus veículos e o controle de licenciamento de cada um deles. Porém, um cliente poderá ter mais de um veículo e também cada veículo poderá ter vários licenciamentos. Para os clientes precisamos armazenar o CPF, nome, telefone e o e-mail e, do seu veículo precisamos guardar a marca, o modelo, o ano e a placa. Para o licenciamento precisamos guardar a data que foi licenciado e o valor pago. Além disso, o veículo pode ter multas e das multas armazenamos a data da infração, a quantidade de pontos e o tipo da infração.

REGRA DE NEGÓCIO:

Um cliente possui um ou vários veículos. Um veículo pertence somente a um cliente.

Um veículo possui vários licenciamentos.

E um licenciamento pertence somente a um veículo.

Um veículo pode ter várias multas e um tipo de multa pode ter em vários veículos.

Seite 9

DIAGRAMAS UML

Introdução à UML

Vamos iniciar nosso conteúdo sobre UML!

'No final dos anos 80 e início dos anos 90, tínhamos muitos conflitos de definições e nomenclaturas na área de modelagem. A escolha para utilização de um determinado padrão era definido mais pelo “gosto” pessoal do que por fatores técnicos oferecidos. Então, os três mais respeitados nomes nesse campo, cada qual com seu conceito e implementação de modelo, Ivar Jacobson (OOSE – Object Oriented Software Engineering), Grady Booch (The Booch Method) and James Rumbaugh (OMT – Object Modeling Technique) decidiram por fim aos debates e trabalhar juntos na definição de um modelo único que veio a ser a UML.' (INTRODUÇÃO..., 2009, on-line).

A UML permite que você “desenhe” uma “planta” do seu sistema. Podemos comparar com um engenheiro que vai realizar um projeto sem, antes, ter completado toda a planta que define o desenho da estrutura a ser construída. A experiência do engenheiro garante, até certo ponto, o caminhar do projeto, contudo, se houvesse a planta, os cálculos estruturais e todo o planejamento suportado pelos documentos corretos, o sucesso do projeto seria incomparavelmente maior. O mesmo pode ser aplicado a um projeto de software.

Por meio de conceitos, objetos, símbolos e diagramas, a UML disponibiliza uma forma simples, mas objetiva e funcional, de documentação e entendimento de um sistema. Por exemplo, você pode utilizar os diagramas e arquivos que compõem um modelo UML para o desenvolvimento, apresentação, treinamento e manutenção durante todo o ciclo de vida da sua aplicação. A UML é mais completa que outras metodologias usadas para a modelagem de dados, pois possui, em seu conjunto, os recursos necessários para suprir as necessidades de todas as etapas que compõem um projeto, proporcionando um total controle do projeto.

Apesar de a UML implementar uma modelagem com uma visão orientada a objetos, isso não significa que a ferramenta e a linguagem para a implementação do modelo sejam, também, orientadas a objetos, mas é recomendado que sejam. Este estudo, no entanto, não irá explorar os conceitos de orientação a objetos, e sim a implementação de um modelo UML simples, para início da documentação de um sistema, utilizando dois diagramas implementados pela UML. Entre os diagramas que serão abordados estão o diagrama de casos de uso e o diagrama de classes.

Dentro desse conceito, cabe discutir o que os diagramas têm como objetivo representar como o sistema irá funcionar e como cada peça do sistema trabalhará e irá interagir com as outras peças do sistema. Existem inúmeras ferramentas para modelagem de dados orientados a objetos, entre as quais, podemos citar o Rational Rose, o Model Maker e o Poseidon UML, o que garante uma vantagem, devido à facilidade de leitura dos diagramas, além da facilidade de confeccioná-los. Além dos diagramas citados, a UML disponibiliza outros diagramas, entre os quais, podemos mencionar o Diagrama de objetos, Diagrama de sequência, Diagrama de colaboração, Diagrama de estado, Diagrama de atividade e Diagrama de componentes.

Reflexão

'UML (Unified Modeling Language) é uma família de notações gráficas, apoiada por u m metamodelo único, que ajuda na descrição e no projeto de sistemas de software, particularmente daqueles construídos utilizando o estilo orientado a objetos (OO). Essa d efinição é um tanto simplificada. Na verdade, para diferentes pessoas a UML tem s ignificados diferentes. Isso ocorre devido à sua própria história e às diferentes maneiras de ver o que compõe um processo de engenharia de software eficaz. Como resultado, em grande parte deste capítulo, minha tarefa é armar o cenário para este livro, explicando as diferentes maneiras pelas quais as pessoas vêem e utilizam a UML.

As linguagens gráficas de modelagem existem há muito tempo na indústria d o software. O propulsor fundamental por trás de todas elas é que as linguagens de programação não estão em um nível de abstração suficientemente alto para facilitar as discussões sobre projeto.

Apesar de as linguagens gráficas de modelagem existirem há muito tempo, há u ma enorme controvérsia sobre seu papel na indústria de software. Essas controvérsias afetam diretamente o modo como as pessoas percebem o papel da UML em si. A UML é um padrão relativamente aberto, controlado pelo OMG (Object M anagement Group), um consórcio aberto de empresas. O OMG foi formado para e stabelecer padrões que suportassem interoperabilidade, especificamente a de sistemas o rientados a objetos. Talvez, o OMG seja mais conhecido pelos padrões CORBA (Common Object Request Broker Architecture).

A UML nasceu da unificação das muitas linguagens gráficas de modelagem o rientadas a objetos que floresceram no final dos anos oitenta, início dos noventa. Desde s ua aparição, em 1997, ela fez com que essa torre de Babel fosse resolvida. Trata-se de um serviço pelo qual eu e muitos outros desenvolvedores estamos profundamente agradecidos.'

FOWLER (2011, p. 25)

FOWLER, Martin. UML Essencial. [Digite o Local da Editora]: Grupo A, 2011. E-book. ISBN 9788560031382. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788560031382/. Acesso em: 19 set. 2022.

Conforme o trecho do texto anterior, observa-se que a UML é resultado de um momento em que havia diferentes formas de modelar software orientado a objetos. Assim, era pouco efetiva a comunicação entre a equipe de desenvolvimento. Vamos conhecer como essa linguagem favorece a produtividade da análise e projeto orientado a objetos?

Ao final deste conteúdo, você será capaz de:

Reconhecer a notação da linguagem UML.

Elaborar abstrações de acordo com os componentes da UML.

Contruir modelos UML para visões estáticas e dinâmicas do sistema.

DIAGRAMA de Casos de Uso

O modelo de casos de uso é um dos modelos da UML, composto do diagrama de casos de uso, que apresentam um conjunto de casos de uso, atores e relacionamentos, e de um detalhamento do diagrama de casos de uso, geralmente, uma descrição textual.

O modelo de casos de uso é construído durante as discussões entre os desenvolvedores do sistema de software e os envolvidos (clientes, usuários, áreas da empresa envolvidas direta ou indiretamente no sistema) para especificar os requisitos.

Um modelo de casos de uso apresenta os requisitos funcionais pretendidos do sistema e os elementos externos que interagem com o sistema.

Objetivo principal do modelo de casos de uso

Especificar, visualizar, construir e documentar o comportamento que cada parte do sistema deve ter.

Os casos de uso descrevem os objetivos do sistema e não as funções!

*Clique no recurso para visualizar o texto.*

Detalhando o objetivo principal, obtêm-se objetivos específicos, que são:

O diagrama de casos de uso é elaborado nas fases de planejamento e/ou análise, através da ferramenta CASE System Architect, Rational Rose, dentre outras. O diagrama auxilia, também, nas fases de projeto, implementação e testes.

FIGURA 1 | FASES DE PROJETO - DIAGRAMA DE CASO DE USO

Notação do diagrama de caso de uso

O diagrama de casos de uso é composto, basicamente, por:

FIGURA 2 | CASO DE USO

Um caso de uso é um conjunto de ações que o sistema realiza para produzir um resultado observável para um ator (objetivos do sistema).

FIGURA 3 | ATOR

São elementos externos ao sistema, que interagem com os casos de uso. Consideram-se atores “alguém” ou “alguma coisa” que não faz parte do sistema, mas que interage com ele.

É o papel executado por alguém e não pela pessoa em si. Por exemplo: José é o administrador do sistema e também usuário comum. Os atores serão o administrador e o usuário, e não a pessoa José.

Exemplos de atores: usuários diretos do sistema, sistemas externos que irão interagir com o sistema ou hardware específico.

Associação é um relacionamento entre o ator e o caso de uso.

FIGURA 4 | SIMBOLOGIA DE ASSOCIAÇÃO

Notação complementar do diagrama de caso de uso

Relacionamento entre atores:

FIGURA 5 | EXEMPLO DA NOTAÇÃO DE GENERALIZAÇÃO

Atores podem ter um relacionamento de generalização, representando que possuem características e ações comuns, além de algumas características e ações adicionais diferenciadas. A generalização é representada por uma linha contínua e uma seta em formato de triângulo. Essa seta deve fica apontada para o ator pai (com características e ações comuns) e a outra parte da linha, no ator filho, que herda as características e ações comuns do pai e ainda possui características e ações específicas.

Uma generalização de ator de um tipo de ator (descendente) para outro tipo de ator (ascendente) indica que o descendente herda o papel que o ascendente pode desempenhar em um caso de uso.

Relacionamento entre casos de uso:

Os casos de uso podem ter relacionamentos entre si. Essas relações devem ser analisadas somente após a especificação dos casos de uso, pois, com a descrição detalhada dos casos de uso, podemos verificar possíveis relacionamentos entre eles.

Basicamente, existem três tipos de relacionamento entre casos de uso, que são:

FIGURA 6 | GENERALIZAÇÃO

Como no relacionamento de generalização entre atores, o relacionamento de generalização entre casos de uso é utilizado quando existem dois ou mais casos de uso que têm comportamento, estrutura e finalidade comuns. Quando isso ocorre, pode descrever as partes compartilhadas em um caso de uso novo, que é especializado pelos casos de uso filho.

FIGURA 7 | INCLUSÃO (INCLUDE)

Relacionamento que indica que um caso de uso contém comportamento definido em outro caso de uso, e que toda vez que o caso de uso base for executado, o caso de uso de inclusão relacionado pelo <<include>> também será executado. O relacionamento de inclusão pode ser usado para:

Separar o comportamento do caso de uso base que não seja necessário para compreender a finalidade principal do caso de uso; apenas o resultado é importante;

Separar o comportamento que seja comum a dois ou mais casos de uso.

FIGURA 8 | EXTENSÃO (EXTEND)

Relacionamento que especifica que o comportamento de um caso de uso base pode ser estendido para um outro caso de uso adicional. A extensão é condicional, o que significa que sua execução depende do que tiver acontecido durante a execução do caso de uso base. O relacionamento de extensão pode ser utilizado para:

Mostrar que uma parte de um caso de uso é um comportamento opcional (ou possivelmente opcional) do sistema. Isso faz a diferenciação entre comportamento opcional e comportamento obrigatório em um modelo;

Mostrar que um subfluxo só é executado em determinadas condições excepcionais;

Mostrar que pode haver um conjunto de segmentos de comportamento entre os quais um ou vários podem ser inseridos em um ponto de extensão de um caso de uso base. Os segmentos de comportamento que são inseridos (e a ordem na qual são inseridos) dependerão da interação com os atores durante a execução do caso de uso base;

Podem representar os fluxos alternativos relevantes de um determinado caso de uso. Princípio da extensão:

Ele sempre adiciona comportamento a um caso de uso;

O caso de uso base deve continuar intacto e tendo valor por si próprio;

O comportamento básico do caso de uso estendido deve sempre ficar intacto.

Passo a passo para a elaboração do diagrama de caso de uso

A seguir, são apresentados os passos que podem ser realizados para a elaboração do diagrama de caso de uso.

Tutorial

Passo 1

Identificação dos atores

Listar os possíveis usuários diretos do sistema, os sistemas externos e hardwares específicos. Para isso, pode-se identificar os possíveis atores e objetivos em relação ao sistema (atores x objetivo).

Dicas para encontrar atores:

Inicie identificando os atores;

Trabalhe do específico para o geral;

Não esqueça os atores de suporte;

Considere as informações que você possui (documento de visão, por exemplo);

Lembre que atores nem sempre são pessoas;

Foque na fronteira do sistema;

Identifique as fontes de informação;

Evolua os atores com os casos de uso.

Perguntas para ajudar:

Quem vai fornecer, usar ou remover informações?

Quem usará essa funcionalidade?

Quem está interessado em um determinado requisito?

Em que parte da organização o sistema é usado?

Quem vai dar suporte e manter o sistema?

Quais são os recursos externos do sistema?

Que outros sistemas precisarão interagir com este?

Passo 2

Identificação dos casos de uso

Listar os possíveis objetivos do sistema. Para identificar esses objetivos, algumas questões podem ser feitas:

De quais objetivos do sistema o ator necessita? O que o ator precisa fazer?

O que o ator precisa fazer? O ator precisa calcular, consultar, criar, destruir, modificar ou registrar algum tipo de informação? Por quê?

O ator deve ser notificado sobre eventos do sistema ou precisa notificar o sistema sobre algo? O que esses eventos representam em termos de funcionalidade?

Existem objetivos de comunicação com outros sistemas?

O ator precisa estar informado sobre certas ocorrências no sistema?

Que informações devem ser modificadas ou criadas no sistema?

Complementando:

Não se preocupe com partes comuns (pelo menos, no início);

Não confundir casos de uso com “funções”;

Foque SEMPRE no valor para o ator;

Não esqueça os casos de uso de suporte e operacionais;

Evolua os casos de uso junto com os atores.

Passo 3

Associação entre os atores e casos de uso

Elaboração propriamente dita do diagrama de caso de uso. Deve-se verificar se todo ator possui, pelo menos, uma associação com um caso de uso e se todo caso de uso interage com algum ator.

Descrição do diagrama de casos de uso

Além da notação gráfica, o diagrama de casos de uso deve possuir uma especificação de detalhamento do diagrama de caso de uso. O modelo padrão do RUP (Rational Unified Process) é que será utilizado nas aulas, e aborda os seguintes itens.

catálogo de atores, contendo o nome do ator e uma descrição de cada ator representado no diagrama;

nome do caso de uso;

breve descrição do caso de uso;

fluxo básico (detalhar o passo a passo do caso de uso);

fluxos alternativos (qualquer exceção que ocorra nos passos do fluxo básico deve ser detalhado como fluxo alternativo);

pré-condições (lista de condições que devem ser verificadas antes que o caso de uso comece);

pós-condições (lista de condições que devem ser verificadas depois do fim do caso de uso).

Dicas para escrever casos de uso:

escreva na voz ativa: “O sistema valida a quantidade entrada” em vez de “A quantidade entrada deve ser validada pelo sistema”;

escreva no tempo presente;

descreva as interações que ocorrem entre os atores e o sistema;

Use subfluxos para simplicar descrições complexas;

não encha seu modelo de casos de uso com o CRUD (Create, Read, Update, Delete);

não tenha medo de capturar os detalhes.

Saiba mais

Caso queira, poderá acessar a um tutorial de caso de uso de UML. Indicamos este:

https://www.youtube.com/watch?time_continue=32&v=ab6eDdwS3rA&feature=emb_logo

Considerações e observações

Um caso de uso sempre deve ter um relacionamento com um ator. Isso implica que cada caso de uso deve ter associações de comunicações com os atores. O motivo dessa regra é forçar o sistema a fornecer apenas a funcionalidade de que os usuários precisam e nada mais. Ter casos de uso que ninguém solicita é uma indicação de que algo está errado no modelo de casos de uso ou nos requisitos. Entretanto, há algumas exceções a essa regra:

Um caso de uso filho em um relacionamento de generalização não precisa ter um ator associado a ele se o caso de uso pai está associado a um ator;

Um caso de uso pode ser iniciado de acordo com uma programação (por exemplo, uma vez por semana ou uma vez por dia), o que significa que o relógio do sistema é o iniciador. O relógio do sistema é interno ao sistema, e o caso de uso não é iniciado por um ator, mas por um evento do sistema interno. Se não ocorrer outra interação do ator no caso de uso, ele não terá nenhuma associação com os atores. Contudo, para esclarecer, você pode usar um ator fictício 'tempo' para mostrar como o caso de uso é iniciado nos diagramas de casos de uso.

Na grande maioria das modelagens de diagramas de casos de uso, a notação básica (ator, relacionamento e caso de uso) é suficiente para especificar os requisitos. Isso significa que não necessariamente é obrigatório utilizar herança <<include>> e <<extends>> em toda modelagem de sistemas; inclusive, a notação de <<include>> e <<extends>> pode ser omitida no diagrama e detalhada no passo a passo do fluxo básico e/ou alternativo;

Geralmente, utiliza-se o termo “manter” para indicar ações de incluir, consultar, alterar e excluir. Para isso, pode-se utilizar o estereótipo <<CRUD>> (create, read, update e delete). Com isso, deixamos o detalhamento das funções para a especificação do caso de uso e mantemos o diagrama mais claro.

Após a elaboração do diagrama de caso de uso e das especificações dos casos de uso, deve-se verificar se há a necessidade de criação de generalização entre atores e casos de uso, inclusões (include) e extensões (extend).

Confira o estudo de caso a seguir.

Estudo de caso

“A clínica médica Saúde Perfeita precisa de um sistema de agendamento de consultas e exames. Um paciente entra em contato com a clínica para marcar consultas visando realizar um check-up anual com seu médico de preferência. A recepcionista procura a data e hora disponível mais próxima na agenda do médico e marca as consultas. Posteriormente, o paciente realiza a consulta, e, nela, o médico pode prescrever medicações e exames, caso necessário.”

Com esse cenário simples, começaremos a criar o diagrama de caso de uso. Inicialmente, iremos definir os atores, que serão:

FIGURA 9 | PACIENTE

FIGURA 10 | SECRETÁRIA

FIGURA 11 | MÉDICO

Agora, definiremos as ações de cada usuário:

Recurso lista interativa:

Paciente

Secretária

Médico

Conteúdo

Paciente:

Solicita consulta;

Solicita cancelamento de consulta.

Voltar para a navegação do recurso lista interativa

Depois que definirmos os atores e suas ações, podemos criar o diagrama de caso de uso que irá nos demonstrar, de uma forma clara, a interação entre atores e ações.

FIGURA 12 | DIAGRAMA DE CASO DE USO - ESTUDO DE CASO 'CLÍNICA'

Diagrama de classes

Descrição

O diagrama de classes é o principal digrama da UML, e sendo estático, modela a estrutura do sistema, por meio de atributos, operações e relacionamentos. Uma classe é a descrição de um conjunto de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica.

Aplicação

O diagrama de classes é utilizado para:

Propor a estrutura do sistema;

Auxiliar na definição de componentes e na implementação.

Palavras-chave: estrutura do sistema.

O diagrama de classes é um dos produtos das fases de análise e/ou projeto e pode ser elaborado através de ferramentas CASE. Esse diagrama é o fundamento da modelagem orientada a objetos, auxiliando em toda modelagem, definição dos componentes e codificação.

O diagrama de classes pode ser classificado em dois tipos:

Recurso lista interativa:

Diagrama de classes de análise

Diagrama de classes de projeto

Conteúdo

Diagrama de classes de análise:

Representam as classes de negócio do sistema, sendo um primeiro modelo conceitual para representar elementos do sistema que possuam características, ações e responsabilidades. Com o tempo, as classes de análise evoluem e se transformam em classes de projeto. As classes de análise não devem se preocupar diretamente com a implementação, ou seja, com particularidades da linguagem de programação;

Voltar para a navegação do recurso lista interativa

Confira a figura a seguir, que exemplifica.

FIGURA 13 | FASES DE PROJETO - DIAGRAMA DE CLASSES

Atenção!

Alguns autores, como Scott e Fowler, classificam os diagramas de classes em 3 tipos, sendo:

1) Conceitual, para definir as classes de negócio;

2) Especificação, para definir as interfaces; e

3) Implementação, para definir as classes de implementação.

Para nossas aulas, o diagrama conceitual equivale ao diagrama de classes de análise, e os diagramas de especificação e de implementação serão desenvolvidos em um único, que será o diagrama de classes de projeto.

Notação básico- Diagrama de classes de análise

Recurso lista interativa:

Classe x Objeto

Classe

Conteúdo

Classe x Objeto:

Classe:

Representa algo do mundo real;

Define as características e o comportamento dos objetos.

Objeto:

Uma ocorrência de uma classe;

Criado durante a execução do sistema.

Voltar para a navegação do recurso lista interativa

Uma classe é representada por um retângulo composto de nome da classe, atributos e métodos (ações).

FIGURA 14 | EXEMPLO DE UMA CLASSE

Recurso lista interativa:

Nome da classe

Atributos

Métodos

Conteúdo

Nome da classe:

O nome da classe deve expressar o que a classe representa, podendo ser um texto (substantivo) simples ou composto no singular e iniciado com letra maiúscula.

Voltar para a navegação do recurso lista interativa

Atenção!

Os níveis de acessibilidade de um atributo e/ou um método podem ser:

Pública (+): objetos de quaisquer classes podem acessar o atributo ou o método;

Privada (-): apenas a classe possuidora do método ou do atributo pode ter acesso;

Protegida (#): apenas a classe e as subclasses possuidoras do método ou do atributo podem ter acesso.

Relacionamentos

Um relacionamento é uma conexão entre classes que representa comunicação e interação entre classes.

Os tipos de relacionamentos que podem ser usados são associação (simples, agregação e composição), generalização e dependência.

Associação: é um relacionamento que...

demonstra que uma classe está conectada a outra, com o intuito de comunicação entre elas. A associação, normalmente, é bidirecional. Isso significa que, se um objeto é associado a outro objeto, ambos os objetos se “conhecem”. A associação simples é uma conexão entre classes. Isso é representado por uma linha contínua entre as duas classes. A associação deve possuir um nome, representado próximo à linha de associação, e frequentemente, é um verbo. Também é sugerido que a associação possua uma seta, que indica a direção de leitura. Tanto o nome da associação quanto a seta são importantes para facilitar o entendimento do domínio do problema.

Na associação, deve-se especificar a cardinalidade entre as classes. A cardinalidade é a indicação de quantos objetos podem participar de um relacionamento, ou seja, a multiplicidade. A multiplicidade das associações define todas as possibilidades numéricas de ocorrências entre os objetos.

Exemplo

Exemplos de multiplicidades:

zero a um - (0... 1);

zero a muitos - (0...*) ou (0... n);

um a muitos - (1...*) ou (1... n);

sem indicação - 1;

3 exato - (3);

1 a 3 - (1... 3) ;

série - (1,2,5... 8).

A associação e a cardinalidade entre as classes estão diretamente relacionadas ao domínio do problema. A seguir, o diagrama de classe representa que uma cliente possui um ou n pedidos e que um pedido pertence a somente um cliente.

FIGURA 15 | EXEMPLO DE DIAGRAMA DE CLASSE

Além da associação simples, apresentada acima, existem dois tipos específicos de associação:

Agregação: é um caso especial...

de associação que representa, conceitualmente, que uma ou mais classes fazem parte de uma outra classe (“todo parte”). Contudo, as classes “todo parte” podem 'viver” independentemente. A notação da agregação é um losângulo sem preenchimento.

O diagrama de classes abaixo representa que uma empresa pode ser composta de um ou mais departamentos, sendo que, não necessariamente, ao instanciar a classe Empresa, a classe Departamento deve ser instanciada.

FIGURA 16 | EXEMPLO DE DIAGRAMA DE CLASSES - AGREGAÇÃO

Composição: é um caso especial...

de associação e uma forma de agregação mais forte, emm que o objeto parte depende do objeto todo, ou seja, espera-se que as partes “vivam” e “morram” na totalidade, conjuntamente. A notação da agregação é um losângulo preenchido.

O diagrama de classes a seguir representa que a classe Pedido é composta de uma ou mais classe Informação de envio, aendo que ao instanciar a classe Pedido, a classe Informação de Envio será instanciada “automaticamente”.

FIGURA 17 | EXEMPLO DE DIAGRAMA DE CLASSE - COMPOSIÇÃO

Atenção!

Tanto no caso da agregação como no da composição, o losângulo fica sempre na classe principal. Todas as regras de associação (por exemplo, nome da associação, seta da associação e cardinalidade) são válidas para agregação e composição.

Generalização: é um relacionamento que...

descreve uma relação entre grupos de “coisas” com algo em comum, e demonstra a herança de atributos e operações de uma classe pai para seus filhos. A generalização é utilizada em classes visando à reutilização de implementação.

Atenção!

O “triângulo” (representação da generalização) deve ser representado na classe pai. Não existe cardinalidade no relacionamento de generalização.

A generalização é um processo bottom-up utilizado para simplificar o modelo. A partir das classes mais especializadas, deduzem-se classes mais genéricas contendo associações, atributos e operações que sejam comuns às classes originais. Estes, por sua vez, são reorganizados para conter somente a parte especializada. A especialização é um processo top-down e é utilizada para refinar o modelo. A partir de classes existentes no modelo, procuram-se especializações para o mesmo, como casos particulares da classe genérica, definindo atributos e operações específicos.

O diagrama de classes a seguir representa que um usuário pode ser um cliente ou um administrador. Tanto o cliente como os administradores possuem características (atributos) e ações (operações) comuns, que são representados na classe pai Usuário. E as características (atributos) e ações (operações) específicas ficam nas classes filhas (Cliente e Administrador).

FIGURA 18 | EXEMPLO DE DIAGRAMA DE CLASSES - GENERALIZAÇÃO

Dependência: é um relacionamento de...

utilização, determinando que uma classe utilize atributos e operações de outra classe, mas não necessariamente, o inverso.

A classe "Detalhes do pedido" depende da classe "Pedido", pois se considera, nesse exemplo, que, ao listar um pedido, os detalhes do pedido devem ser exibidos.

FIGURA 19 | EXEMPLO DE DIAGRAMA DE CLASSES - DEPENDÊNCIA

Procedimento para a elaboração do diagrama de classes de análise

Identificação das classes

Descrição

A primeira fase da elaboração de um modelo de classes consiste na identificação das classes que comporão o sistema. A partir da descrição textual do sistema (especificação de requisitos) e/ou dos diagramas e descrições dos casos de uso, serão identificadas as classes relevantes através de sucessivos refinamentos e detalhamentos, ou seja:

Foco nas classes de negócio;

Classes se originam de:

Especificações de requisitos;

Diagramas de casos de uso;

Modelos de processo;

Entrevistas;

Reuniões.

Confira a seguir, a estrutura da solução.

Tutorial

Identificação

Identifique os substantivos na descrição do sistema (requisitos, especificação de casos de uso, diagrama de casos de uso, etc.);

Classificação

Anote-os separadamente e classifique-os;

Avaliação

Refine os objetos identificados, avaliando os que devem permanecer no modelo;

Esboço

Crie um esboço do diagrama com os objetos identificados;

Não se preocupe com atributos, operações e relacionamentos;

Tente refiná-los, agrupando os objetos fortemente relacionados.

Atenção!

Perguntas para auxiliar na identificação de classes:

Existem informações que devem ser armazenadas?

Existem sistemas externos?

Existem representações organizacionais?

Os atores representam algo no negócio?

Existem dispositivos utilizados pelo sistema?

Existem bibliotecas, componentes ou outros elementos de software?

Dirija a modelagem segundo o problema a resolver;

Escolha os nomes das classes com critério;

Analise cuidadosamente o texto, examinando, também, pronomes, para não omitir substantivos implícitos;

Não elimine classes a não ser que tenha absoluta certeza. É sempre possível eliminar uma classe mais tarde;

Planeje a localização de suas classes no diagrama, facilitando enxergar os relacionamentos.

Identificação de associação entre classes

Descrição

Após a identificação das classes que fazem parte do sistema, é necessário relacionar as classes de acordo com os seus papéis. Uma classe isolada no sistema, geralmente, não é útil; portanto, toda classe tem algum tipo de relacionamento com outra classe. É necessário identificar, inicialmente, as associações e agregações entre as classes do sistema e, posteriormente, as generalizações/herança.

Estrutura da solução:

Associações

Cardinalidades

Hierarquia de generalização/herança

Atenção!

As cardinalidades dizem respeito a cada extremidade de uma associação;

As cardinalidades podem mudar dependendo do contexto em que a associação ocorre, do domínio do problema e das regras de negócio.

Identificação de atributos e operações

A definição dos atributos e operações na classe é baseada nas responsabilidades. Responsabilidade é um contrato de uma determinada classe.

Exemplo

Por exemplo, uma classe Sensor é responsável por medir a temperatura e disparar um alarme, caso a temperatura alcance um determinado ponto. Nesse exemplo, é fácil identificar os atributos (valor temperatura obtida, valor temperatura máxima) e operações (medir temperatura e disparar alarme).

Ao realizar a modelagem, um bom ponto de partida para identificar as responsabilidades: técnicas como CRC (Class Responsability Collaboration) e análises baseadas em casos de uso são de grande ajuda.

Recurso lista interativa:

Estrutura da solução para atributos

Estrutura da solução para operações

Conteúdo

Estrutura da solução para atributos:

A partir da descrição textual do problema, tente identificar substantivos e adjetivos que representem propriedades das classes identificadas;

Tente descobrir mais alguns atributos através de análise e discussão. Atributos podem ser omitidos da descrição, mas o conhecimento do domínio da aplicação traz à tona muitos atributos implícitos;

Complete o modelo de classes com os atributos encontrados e verifique se estão na classe correta.

Voltar para a navegação do recurso lista interativa

Atenção!

Atributos podem ser identificados como novas classes, dependendo do contexto. Se um atributo tem atributos, então, ele é uma classe. Se a existência do atributo parece mais importante que o valor que ele guarda, então, ele é uma classe.

Observe o nível adequado de detalhamento. Alguns atributos são mais importantes que outros. Atributos que afetam muitas operações da aplicação são altamente relevantes. Outros atributos que têm efeito pequeno não necessitam ser considerados na análise.

Cuidado com atributos necessários à implementação. Alguns atributos podem ser necessários somente para a linguagem em que será implementado o aplicativo, mas podem não ter função lógica no domínio da aplicação. Não considere esses atributos no diagrama de classes de análise.

Verifique atributos fora de contexto. Se forem identificados grupos de atributos que não se relacionam dentro de uma classe, examine melhor essa classe. Pode ser interessante dividi-la em mais classes, com os atributos mais relacionados juntos.

Aproveite a identificação dos atributos para rever as suas classes. Algumas classes podem estar fora de foco, sem função definida no sistema.

Algumas características de seleção de classes são sugeridas por Coad e Yourdon:

A classe será útil somente se a informação sobre ela for necessária para o funcionamento do sistema;

A classe em potencial deve ter um conjunto de operações identificáveis que podem mudar o valor de seus atributos de alguma maneira;

Uma classe com um único atributo, provavelmente, será mais bem representada como um atributo de outra classe.

Algumas dicas para análise das descrições gramaticais de sistemas são sugeridas por Abbot:

QUADRO 1 | DICAS PARA ANÁLISE DAS DESCRIÇÕES GRAMATICAIS DE SISTEMAS

Diagramas de interação

Descrição

Os diagramas de interação modelam o comportamento dinâmico dos objetos.

Recurso lista interativa:

A interação pode representar:

Conteúdo

A interação pode representar::

Chamada de uma operação;

Envio de um sinal;

Mensagem para criação ou destruição de objetos.

Voltar para a navegação do recurso lista interativa

Os diagramas de interação são divididos em dois diagramas: sequência e colaboração (comunicação na UML 2.0).

Recurso lista interativa:

São construídos a partir de cenários de casos de uso:

Diagrama de sequência

Diagrama de colaboração (comunicação)

Conteúdo

São construídos a partir de cenários de casos de uso::

É a realização de um caso de uso;

Representam os vários caminhos para a realização de uma tarefa;

Podem ser possibilidades de sucesso ou de insucesso;

Identificados a partir do fluxo principal e dos fluxos alternativos dos casos de uso.

Voltar para a navegação do recurso lista interativa

Como ambos são derivados das mesmas informações de um modelo da UML (diagrama de classes), o diagrama de sequência e o diagrama de colaboração (comunicação) são semanticamente equivalentes, mas com enfoque de visualização diferente. Devido a isso, um diagrama de sequência pode ser convertido em um diagrama de colaboração (comunicação) e vice-versa. Geralmente, as ferramentas CASEs auxiliam nessa conversão, pois, elaborando um dos diagramas, o outro é gerado automaticamente.

Aplicação

É utilizado para modelar aspectos dinâmicos do sistema; visualizar, especificar, construir e documentar a dinâmica de determinados objetos; modelar determinado fluxo de controle de um caso de uso e validar o diagrama de classes.

Palavras-chave: modelo dinâmico, objeto.

FIGURA 20 | FASES DE PROJETO - DIAGRAMA DE SEQUÊNCIA

Os diagramas de interação são um dos produtos das fases de análise e/ou projeto. Os diagramas de interação auxiliam também nas fases de implementação e de testes.

Notação

Diagrama de sequência

Preocupa-se com a ordem de tempo em que as mensagens são trocadas entre os objetos envolvidos em determinado processo, ou seja, quais condições devem ser satisfeitas e quais métodos devem ser disparados entre os objetos envolvidos e em que ordem durante um processo. Dessa forma, um diagrama de sequência, determina a ordem em que ocorrem os eventos, a ordem das mensagens enviadas e como os objetos interagem entre si dentro de um determinado processo.

Segundo Guedes (2018), em seu livro “UML: uma abordagem prática”, normalmente, existem diversos diagramas de sequência em um projeto, um para cada processo específico do sistema. Isso exemplifica que o diagrama de sequência baseia-se no diagrama de casos de uso, contudo, o fato de existir apenas um diagrama de casos de uso não implica na existência de apenas um diagrama de sequência. O que acontece é que um diagrama de sequência, em geral, identifica-se com um determinado caso de uso e, desse modo, o diagrama de sequência também permite documentar um caso de uso.

É interessante sempre relembrar que...

nem todo caso de uso gera, obrigatoriamente, um diagrama de sequência, por exemplo: os casos de uso que não têm uma associação direta com um ator, sendo associado a outro caso de uso através de um <<include>>. Esses casos de uso precisam ser executados com os outros casos de uso que os utilizam e, muitas vezes, suas etapas são apresentadas no mesmo diagrama de sequência. Porém, nada impede que se defina um diagrama de sequência exclusivo para casos de uso que são utilizados por outros casos de uso por meio da associação <<include>>.

O diagrama de sequência depende, também, do diagrama de classes, uma vez que as classes dos objetos declarados no diagrama estão citadas nele.

Os elementos para a construção de um digrama de sequência são:

FIGURA 21 | ATORES

Possuem a mesma descrição e conceitos presentes no diagrama de caso de uso. São entidades externas que realizam interações com o sistema através de suas funcionalidades.

FIGURA 22 | OBJETO

São as instâncias de uma classe, possuem nome do objeto, nome da classe e são separados por dois pontos.

Especificação da execução

Representa o período em que o objeto desempenha uma ação.

FIGURA 23 | LINHA DE VIDA

Representa a existência do objeto em um período de tempo.

FIGURA 24 | ATIVAÇÃO

É o estímulo recebido pelo objeto e pela ação realizada.

Mensagens

Mensagens entre os objetos.

Existem as seguintes mensagens:

Recurso lista interativa:

Seta com ponta cheia

Seta com ponta aberta

Seta com linha interrompida

Conteúdo

Seta com ponta cheia:

Representa:

Chamada de procedimento (operação/método);

Objeto concorrente que envia um sinal e aguarda o fim da execução de atividades aninhadas.

Voltar para a navegação do recurso lista interativa

Regras

Um único diagrama de interação não é capaz de captar tudo sobre os aspectos dinâmicos do sistema, por isso, utilize diversos diagramas de interação para fazer a modelagem dinâmica do sistema. Crie diversas situações (cenários) para o sistema e elabore os diagramas de interação correspondentes.

Os objetos somente podem se comunicar nos diagramas de interação caso exista um relacionamento entre as classes correspondentes no diagrama de classes.

As operações executadas pelos objetos devem estar representadas no diagrama de classes. As mensagens podem ter a assinatura dos métodos das classes. Os retornos nem sempre são exibidos, mas somente os relevantes.

Construção

Podem ser construídos para:

Fluxo principal dos casos de uso;

Fluxos alternativos.

Não é necessário criar o diagrama para todos os cenários. Considere sempre os cenários mais relevantes (necessitam de detalhes);

A troca de mensagem auxilia na identificação de novas operações para as classes envolvidas na interação.

Para cada cenário:

Tutorial

Definição

Defina o cenário que irá representar;

Identificação

Identifique os objetos que participam da interação;

Alinhamento

Coloque o objeto que inicia a interação à esquerda e os demais à direita, de acordo com sua participação na interação;

Ordenação

Coloque as mensagens que os objetos enviam e recebem na ordem crescente de tempo e de cima para baixo;

Importância

Coloque as mensagens de retorno relevantes para o cenário.

A seguir serão demonstrados alguns exemplos de diagrama de sequência:

Exemplo

Mensagens, comunicação entre atores ou objetos.

Saiba mais

Para saber mais, confira o vídeo 'Criando diagrama de sequência'.

Acesse: https://www.youtube.com/watch?v=ypP6HQdDxYM&t=720s&ab_channel=EstudoNaWeb

Agora que você conhece o diagrama de classes e o diagrama de sequência, realize a leitura indicada a seguir. A partir dela, você irá perceber que, ainda que tenham objetivos diferentes, esses modelos em conjunto oferecem a abstração completa da troca de mensagens entre os objetos.

Estudo Guiado

Leia os capítulos 3, 4 e 5 do livro de Martin Fowler, os quais oferecem uma visão detalhada de como modelar classes que serão programadas..

Clique no link e leia o livro

Diagrama de atividade

O diagrama de atividades ilustra graficamente como serão o funcionamento do software, a execução de alguma de suas partes, a atuação do sistema na realidade de negócio na qual ele está inserido.

O objetivo do diagrama de atividades é mostrar o fluxo de atividades em um único processo. O diagrama mostra como uma atividade depende da outra, sendo muito parecido com um fluxograma.

Recurso lista interativa:

Podem especificar:

Conteúdo

Podem especificar::

Modelo de negócio – sistema todo;

Detalhar um caso de uso;

Descrever uma operação de uma classe.

Estado da atividade e estado da ação;

Transições;

Ramificações;

Bifurcação e união;

Raias.

Voltar para a navegação do recurso lista interativa

No fluxo de controle modelado por um diagrama de atividade, as coisas acontecem. É possível calcular uma expressão que defina um conjunto de valor de um atributo ou que retorne algum valor. Os estados de ação não podem ser decompostos.

FIGURA 25 | ESTADO INICIAL

Determina que o diagrama inicia em algum lugar.

É obrigatório;

Somente um estado inicial é permitido.

FIGURA 26 | ESTADO FINAL

É o estado que indica o fim do ciclo de vida de um objeto.

É opcional;

Pode não existir se o fluxo é infinito;

Representação.

FIGURA 27 | TRANSIÇÃO

Quando uma ação ou atividade está completa, o fluxo de controle passa para a atividade seguinte;

Esse fluxo é representado pelas transições.

FIGURA 28 | RAMIFICAÇÕES

São caminhos alternativos de um fluxo de controle;

Podem ter uma transição de entrada e duas ou mais de saída;

Em cada transição de saída, é colocada uma expressão booleana, avaliada após a entrada na ramificação.

FIGURA 29 | BIFURCAÇÃO

Uma bifurcação representa a divisão de um mesmo fluxo de controle em dois ou mais fluxos de controle concorrentes;

A bifurcação poderá ter uma única transição de entrada e duas ou mais transições de saída, cada uma das quais representa um fluxo de controle independente.

FIGURA 30 | UNIÃO

Uma união representa a sincronização de dois ou mais fluxos de controle concorrentes;

A união poderá ter duas ou mais transições de entrada e uma única transição de saída.

FIGURA 31 | RAIAS

Particiona as atividades em grupos;

Cada grupo representa um responsável pelas atividades;

Cada grupo é colocado em uma raia e deve ter nome único;

Muito útil no mapeamento de fluxos de negócio.

A seguir, será demonstrado um exemplo do diagrama de atividade (Realizar saque):

FIGURA 32 | EXEMPLO DO DIAGRAMA DE ATIVIDADE (REALIZAR SAQUE)

Seite 10

MODELO FÍSICO DE DADOS

Nesta unidade de ensino, será visto o Modelo Físico de Dados, que tem o objetivo de transformar as entidades em tabelas com colunas e os tipos de dados que serão criados no SGBD (Sistema Gerenciador de Banco de Dados) escolhido, utilizando a Linguagem de Consulta Estruturada, a SQL (Structured Query Language).

Ao final deste conteúdo, você será capaz de:

Reconhecer as operações para criação e manipulação de banco de dados.

Elaborar instruções para criação e manipulação de banco de dados.

Implementar instruções em SQL.

Antes de iniciarmos, confira o quadrinho apresentado a seguir.

Quadrinho

Bons estudos!

Modelo físico de dados

A última etapa do projeto de banco de dados é chamada de projeto físico, durante a qual as estruturas de armazenamento internas, organizações de arquivos, índices, caminhos de acesso e parâmetros físicos do projeto para os arquivos do banco de dados são especificados (ELMASRI; NAVATHE, 2018).

O modelo físico de dados é construído com base no modelo lógico de dados. Nesse modelo, são descritas as estruturas físicas do banco de dados e, por isso, deve-se considerar o SGBD que será utilizado para a implementação. A implementação do banco de dados consiste na criação das estruturas físicas que darão suporte ao processo de armazenamento e à manutenção dos dados, tais como tabelas, índices, restrições, dentre outros elementos.

O modelo físico de dados representa a estrutura para armazenamento físico dos dados, expressando a forma como as informações serão armazenadas fisicamente, em termos computacionais (PUGA; FRANÇA; GOYA, 2013).

Pode-se ainda, representar o modelo externo, isto é, as aplicações ou sistemas que utilizam o banco de dados, no qual são expressas as diversas formas particulares como os dados da organização são visualizados e manipulados pelos sistemas.

Na etapa do desenvolvimento do modelo físico de dados, devem ser considerados os aspectos relacionados ao SGBD escolhido para implementação do modelo. Nesse caso, os nomes dos tipos de dados e a implementação das regras devem ser conforme a plataforma adotada pelo SGBD.

O modelo físico, ao ser implementado, relaciona-se com diversos sistemas ou aplicações que necessitam de dados.

Na etapa do modelo físico, são criadas as estruturas físicas, isto é, a estrutura de dados conforme o SGBD escolhido.

Para aprofundar seu conhecimento, confira a leitura indicada a seguir.

Estudo Guiado

Capítulo 7: “Implementação do modelo físico de dados”. Leia as páginas 169 a 190.

Clique no link e leia o livro

PUGA, S.; FRANÇA, E.; GOYA M. Banco de dados: implementação em SQL, PL/SQL e Oracle 11G. São Paulo: Pearson, 2013.

Para maiores informações, acesse o curso DataBase Foundations, da Oracle Academy: "Mapeando entidades e atributos".

Saiba mais

DataBase Foundations: 'Mapeando entidades e atributos'.

Abrir pdf

SQL

A linguagem padrão para banco de dados relacionais é a SQL, sigla para Structured Query Language (Linguagem Estruturada para Consulta).

Há diversos sistemas gerenciadores de banco de dados relacional (SGBDR) que possibilitam a utilização da linguagem SQL e que também oferecem recursos para administração e manutenção do banco de dados.

Durante o desenvolvimento dos bancos de dados relacionais, foram criadas linguagens destinadas à manipulação. No início dos anos 1970, o Departamento de Pesquisas da IBM desenvolveu a linguagem SQL como forma de interface para o sistema de banco de dados relacional: a SYSTEM R. Inicialmente, o SQL era denominado SEQUEL (Structured English Query Language).

Em 1977, essa nomenclatura foi revisada e passou a ser chamada Structured Query Language (SQL).

Em 1986 o Instituto Nacional Americano de Padrões – American National Standard Institute – (ANSI), em conjunto com a Organização Internacional de Padrões, a International Standards Organization (ISO) publicou um padrão de linguagem SQL, conhecida como SQL-86, ou SQL-1, tornando-se a linguagem padrão adotada para bancos de dados relacionais: os diferentes SGBDR, tais como Oracle, SQL SERVER, DB2, PostgreSQL, MySQL, dentre outros.

Categorias de linguagem SQL

A linguagem SQL possui as seguintes categorias de instruções, conforme apresentado no quadro a seguir:

QUADRO 1 | CATEGORIA DAS INSTRUÇÕES SQL

CATEGORIADESCRIÇÃOINSTRUÇÕES

DDL - Data Definition LanguageDefinição e descrição dos dados.CREATE, ALTER, DROP, RENAME, TRUNCATE, COMMENT.

DML - Data Manipulation LanguageManipulação dos dados,INSERT, UPDATE, DELETE, SELECT, MERGE.

TCL - Transact Control LanguageUsada nos controles de transações; trabalha com as instruções DML.COMMIT, ROLLBACK, SAVEPOINT

DCL - Data Control LanguageControle de acesso aos dados.GRANT, REVOKE

PUGA; FRANÇA; GOYA, 2013 [ADAPTADA].

Software Oracle

O Oracle DataBase Express Edition (XE) é um software gratuito, usado por desenvolvedores, DBAs, cientistas de dados, educadores, etc. O Oracle XE é a maneira ideal de começar. É o mesmo Oracle Database avançado, no qual empresas de todo o mundo confiam, formatado para download simples, facilidade de uso e experiência completa (ORACLE ACADEMY, 2020).

Atenção!

INSTALAÇÃO DO ORACLE

A instalação do banco de dados Oracle Express Edition (XE) é bem simples. Possui versão para Windows e Linux. A única informação solicitada é uma senha para o usuário administrativo (SYSTEM).

Necessário ter conta na Oracle Academy.

Curiosidade

HISTÓRIA DA ORACLE A Oracle foi fundada em agosto de...

HISTÓRIA DA ORACLE

A Oracle foi fundada em agosto de 1977. Inicialmente, era denominada Software Development Labs (SDL), uma empresa de consultoria que contava com Bob Miner (presidente), Ed Oates e Bruce Scott (engenheiros de software) no seu primeiro projeto. Larry Ellison, um dos grandes nomes da Oracle, trabalhava na empresa para a qual a SDL prestava a consultoria.

Esse Bruce Scott é o Scott de ‘scott/tiger’ (Tiger era o nome do gato da sua filha), usado até hoje nos schemas de exemplo do sistema gerenciador de banco de dados (RDBMS) desenvolvido pela empresa.

Antes de formar a Oracle, Bob Miner foi gerente de Larry Ellison em um projeto da CIA, apelidado de “Oracle”. Ed Oates e Bruce Scott fizeram 90% do trabalho de dois anos (desse projeto de consultoria), no primeiro ano, de modo que tiveram o ano seguinte para trabalhar no Oracle.

Ed Oates terminou os outros 10% no ano seguinte, enquanto Bob e Scott começaram a escrever o banco de dados Oracle.

Quando concluíram o trabalho, decidiram que queriam ser uma empresa de produto, em vez de uma empresa de consultoria.

Mas Larry não estava interessado nisso. Estava acompanhando o que a IBM estava fazendo e descobriu um trabalho sobre o System/R baseado no trabalho de 1970 de Codd sobre bancos de dados relacionais. Ele descrevia a linguagem SQL, que, na época, era chamada SEQUEL/2.

Larry levou o trabalho a Bob e Scott e perguntou-lhes se poderiam montar isso. Julgaram que seria muito fácil e assim começaram.

Scott tinha 24 anos na época; Bob era 15 anos mais velho e Larry, 10 anos mais velho do que Sccott. Scott deixou a Oracle em 1982, depois de cerca de cinco anos e meio trabalhando lá.

Quando saiu, tinham terminado a versão 3 do banco de dados. Cerca de metade do código era de Scott e metade, de Bob. Parte do código do analisador no banco de dados atual ainda pode ser de Scott. Este falou de um dia que marcou a sua vida: a conferência dos primeiros usuários do Oracle.

Essa foi uma conferência de clientes que organizaram. Aconteceu em 1982 e reuniu de 25 a 50 pessoas.

A seguir, são apresentados os passos para acessar o banco de dados Oracle Express Edition, selecionando a opção Conceitos Básicos, pela primeira vez:

FIGURA 1 | PASSO 1

FIGURA 2 | PASSO 2

FIGURA 3 | PASSO 3

FIGURA 4 | PASSO 4

FIGURA 5 | PASSO 5

FIGURA 6 | PASSO 6

FIGURA 7 | PASSO 7

FIGURA 8 | PASSO 8

FIGURA 9 | PASSO 9

Após o primeiro acesso ao Oracle Express Editon, siga os passos a seguir:

FIGURA 10 | PASSO 1

FIGURA 11 | PASSO 2

FIGURA 12 | PASSO 3

FIGURA 13 | PASSO 4

FIGURA 14 | PASSO 5

FIGURA 15 | PASSO 6

O seguinte estudo de caso será usado no vídeo sobre o uso do software Oracle Express Edition:

Estudo de caso

ESTUDO DE CASO: CONTROLE DE VENDAS DE UM PRODUTO

A loja de departamentos deseja informatizar o seu sistema, que armazena informações dos clientes, produtos e vendas. Para isso, precisa guardar:

- PRODUTO:

cd_produto INTEGER PRIMARY KEY

nm_produto VARCHAR(50) NOT NULL

vl_produto NUMBER(8,2)

- CLIENTE:

cd_cliente INTEGER PRIMARY KEY

nm_cliente VARCHAR(50) NOT NULL

dt_cadastro DATE DEFAULT SYSDATE

- VENDA:

dt_venda DATE SYSDATE

vl_total NUMBER(10,2)

- ITEM_VENDA:

qt_vendida INTEGER

vl_total_item NUMBER(8,2)

REGRA DE NEGÓCIO:

Um PRODUTO possui muitas VENDAS;

Um VENDA tem muitos PRODUTOS;

Um CLIENTE efetua muitas compras, por meio das VENDAS;

Uma VENDA pertence a um CLIENTE;

Entre as tabelas PRODUTO e VENDA, terá um ITEM_VENDA.

Abrir pdf

Videoaula

Esquema de banco de dados

O esquema de banco de dados detalhado descreve os conceitos (entidades e atributos) e relacionamentos de um minimundo, baseado na realidade, e está relacionado a um usuário no banco de dados.

Para aprofundar seu conhecimento, confira as leituras indicada a seguir.

Estudo Guiado

Capítulo 8: “Manipulação de dados operação DML”. Leia as páginas 195 a 202.

Clique no link e leia o livro

PUGA, S.; FRANÇA, E.; GOYA M. Banco de dados: implementação em SQL, PL/SQL e Oracle 11G. São Paulo: Pearson, 2013.

Estudo Guiado

Capítulo 9: “Consulta de dados”. Leia as páginas 207 a 221.

Clique no link e leia o livro

PUGA, S.; FRANÇA, E.; GOYA M. Banco de dados: implementação em SQL, PL/SQL e Oracle 11G. São Paulo: Pearson, 2013.

No curso DataBase Foundations, leia o capítulo "Introdução à SQL".

Saiba mais

'DataBase Foundations: introdução à SQL'.

Abrir pdf

Estudo de caso

A seguir, será apresentado o estudo de caso para exemplificar os comandos da linguagem SQL:

Estudo de caso

Um centro médico deseja informar o seu controle de atendimentos. Nesse centro médico, há especialidades médicas, pacientes, convênios e atendimentos.

Esses atendimentos podem ser consultas, exames e terapias.

ESPECIALIDADE MÉDICA: sigla e nome.

MÉDICOS: CRM, nome, telefone e horário de atendimento;

PACIENTES: CPF, nome, telefone de contato e data de nascimento;

CONVÊNIOS: CNPJ, razão social e e-mail;

TIPOS DE ATENDIMENTOS: sigla, nome;

ATENDIMENTOS: data e hora do atendimento, se é particular ou pelo convênio.

REGRA DE NEGÓCIO:

Uma ESPECIALIDADE MÉDICA tem muitos MÉDICOS, e um MÉDICO pode ter uma ESPECIALIDADE MÉDICA;

Um CONVÊNIO pode ter muitos PACIENTES, e um PACIENTE tem somente um CONVÊNIO;

Um TIPO DE ATENDIMENTO tem muitos ATENDIMENTOS, e um ATENDIMENTO pertence a um TIPO DE ATENDIMENTO;

Um MÉDICO atende muitos PACIENTES, e um PACIENTE é atendido por muitos MÉDICOS.

Data de Definition Language (DDL)

Os comandos da linguagem SQL classificamos como DDL (Data Definition Language, Linguagem de Definição de Dados) são iniciados com as palavras reservadas: CREATE, ALTER, DROP, TRUNCATE, RENAME, FLASHBACK e COMMENT.

No DDL, os principais objetos são: TABLE, VIEW, SEQUENCE, SYNONYM, INDEX, entre outros.

Tabelas

A tabela é o local lógico onde são armazenados os dados (antigamente chamávamos de arquivos). Uma tabela é formada de colunas (antigamente chamávamos campos. E cada tabela pode ter até 1600 colunas) e linhas (antigamente chamávamos de registros).

Não é necessário especificar o tamanho de nenhuma tabela. O tamanho é definido pela quantidade de espaço alocada no banco de dados como um todo. Entretanto, é importante estimar a quantidade de espaço que um exercício usará. Para criarmos uma tabela no ORACLE, é necessário que o usuário defina para cada coluna, o tipo de dado, o tamanho e as suas restrições (ELMASRI e NAVATHE, 2018).

A Tabela a seguir, apresenta os principais tipos de dados:

TABELA 1 | TIPOS DE DADOS

TIPODESCRIÇÃOTAMANHO MÁXIMOEXEMPLO

CHAR(tamanho)Alfanumérico de tamanho fixo.2000 bytes(caracteres)unidade_federativa

VARCHAR(tamanho)Alfanumérico. O que não foi utilizado não ocupa espaço no banco de dados.4000 bytes caracteres)endereco_aluno

LONGAlfanumérico. Tamanho não precisa ser informado. Só pode existir um por tabela e não pode ser utilizado em consultas.2 Giga bytes (caracteres)curriculo_professor

DATEData. Serão armazenados com século, ano, mês, dia, hora, minuto e segundo. data_nascimento

NUMBER(precisão,escala)Numérico. Utilizado com casas decimais, primeiro o número total de dígitos (incluindo as casas decimais (escala opcional))38valor_produto

INTEGERNúmeros inteiros. Não aceita limitação de tamanho do campo38idade_funcionario

ADAPTADO DE PUGA; FRANÇA; GOYA, 2013

Criar tabela (create table)

O comando para criar tabelas no banco de dados é CREATE TABLE. Sua sintaxe é:

CREATE TABLE nome-da-tabela

(nome-da-coluna tipo-de-dado1 [(tamanho)] [restrições],

nome-da-coluna tipo-de-dadon [(tamanho)] [restrições]..);

Atenção!

Para criar uma tabela é necessário precisa ter Grant (privilégio) de CREATE TABLE e possuir uma área de armazenamento.

Restrições de tabelas

As restrições, também chamadas de constraints, são regras básicas para o preenchimento de uma ou mais colunas da tabela e são definidas ao final da especificação de cada coluna ou no final do comando. Toda restrição possui um nome que pode ser definido pelo usuário, por meio da opção CONSTRAINT; caso contrário, receberá um nome padronizado. Os tipos de restrições são: chaves primárias, chaves únicas, chaves estrangeiras e identificadores de campos obrigatórios.

A Tabela a seguir. apresenta os tipos de restrições e, na sequência, veremos cada uma.

TABELA 2 | TIPOS DE CONSTRAINNTS

TIPO DE RESTRIÇÃODESCRIÇÃOSINTAXE

DEFAULTPodemos informar um valor padrão quando este não for fornecido pelo usuário. Dessa forma, não haverá valores nulos na coluna. Pode ser um literal, uma expressão ou uma função SQL (SYSDATE (data do sistema) ou USER (usuário logado) e deve corresponder ao tipo de dados da coluna.coluna tipo-de-dado(tamanho) DEFAULT valor padrão;

PRIMARY KEYDefine que uma ou mais colunas fazem parte da chave primária de uma tabela. Esta constraint significa que a coluna deve ser única e com preenchimento obrigatório. Uma tabela tem somente uma chave primária, que pode ter uma ou mais colunas.

coluna tipo-de-dado(tamanho) PRIMARY KEY;

CONSTRAINT nome_pk PRIMARY KEY (coluna,colunan);

FOREIGN KEYPossui a mesma função de REFERENCES, mas somente pode ser declarada ao final de todas as colunas. Nesse tipo de constraint, os relacionamentos que utilizam mais de uma coluna (chave composta) podem ser criados. Uma tabela pode ter muitas chaves estrangeiras.

CONSTRAINT nome_fk

FOREIGN KEY (nome_coluna)

REFERENCES nome_tabela (nome_coluna_chave_primária);

CHECKDefine um conjunto de valores permitidos ou condição para inserção ou atualização de valores em uma determinada coluna.

CONSTRAINT nome_ch CHECK (coluna possíveis valores);

NOT NULLIndica que é obrigatória a inserção de algum valor nessa coluna. Somente pode ser declarado com a coluna

coluna tipo-dado NOT NULL;

UNIQUEIndica que não poderá ter mais de uma tupla com o mesmo conteúdo dentre todos os registros da tabela.

CONSTRAINT nome_uk UNIQUE(coluna);

INSTITUCIONAL, 2022.

Visualizar a estrutura de uma tabela

A instrução DESC – ou DESCRIBE – exibe o nome das colunas, as restrições (chave primária e preenchimento obrigatório), tipo de dados, valor padrão (DEFAULT), comentários e quantidade de caracteres de cada coluna. Sintaxe:

DESCRIBE nome_tabela;

Exemplo de criação de tabelas com restrições

FIGURA 16 | CRIAÇÃO DA TABELA ESPECIALIDADE_MEDICA

A Figura a seguir, exemplifica a criação de tabela ESPECIALIDADE_MEDICA com as restrições (constraint) de chave primária nomeada (PRIMARY KEY) e preenchimento obrigatório (NOT NULL) na coluna nm_especialidade:

FIGURA 17 | CRIAÇÃO DA TABELA MEDICA

A Figura a seguir, exemplifica a criação da tabela MEDICO, com as restrições (constraint) de chave primária nomeada(PRIMARY KEY) e preenchimento obrigatório (NOT NULL), na coluna nm_medico:

FIGURA 18 | CRIAÇÃO DA TABELA CONVENIO

A Figura a seguir, exemplifica a criação da tabela CONVENIO, com as restrições (constraint) de chave primária nomeada(PRIMARY KEY), preenchimento obrigatório (NOT NULL), na coluna nm_razao_social e e-mail com a restrição única (UNIQUE):

FIGURA 19 | CRIAÇÃO DA TABELA PACIENTE

A Figura a seguir, exemplifica a criação da tabela PACIENTE, com as restrições (constraint) de chave primária (PRIMARY KEY) e chave estrangeira (FOREIGN KEY), com a tabela CONVENIO:

FIGURA 20 | CRIAÇÃO DA TABELA TIPO_ATENDIMENTO

A Figura a seguir, exemplifica a criação da tabela TIPO_ATENDIMENTO com a restrição (constraint), de chave primária (PRIMARY KEY):

FIGURA 21 | DESCRIÇÃO DA TABELA TIPO_ATENDIMENTO

A Figura a seguir, exemplifica o comando DESC, que exibe a estrutura da tabela TIPO_ATENDIMENTO:

FIGURA 22 | CRIAÇÃO DA TABELA ATENDIMENTO

A Figura a seguir, exemplifica a criação da tabela ATENDIMENTO, com as restrições de valor padrão para preenchimento (DEFAULT), chave primária composta ou concatenada (PRIMARY KEY), chave estrangeira (FOREIGN KEY) e checagem de valores de entranda (CHECK):

FIGURA 23 | CRIAÇÃO DA TABELA CLIENTE COM BASE NA TABELA PACIENTE

A Figura a seguir, exemplifica a criação da tabela CLIENTE, com base na tabela PACIENTE, renomeando e restringindo as colunas:

Alterar tabela (alter tabela)

Após a criação da estrutura de uma tabela, podemos incluir, renomear, excluir ou modificar colunas e incluir, excluir, habilitar ou desabilitar constraints dessa tabela, com o comando DDL, ALTER TABLE, cuja sintaxe é:

Adicionar colunas

ALTER TABLE nome-da-tabela

ADD (nome-da-coluna tipo-de-dado [(tamanho)]);

FIGURA 24 | ALTERAÇÃO DA TABELA COM ADIÇÃO DE COLUNAS

A Figura a seguir, exemplifica a adição da coluna vl_atendimento NUMBER(8,2) com valor padrão (DEFAULT) igual a 0, na tabela ATENDIMENTO:

FIGURA 25 | ALTERAÇÃO DE TABELAS COM ADIÇÃO DE COLUNA

A Figura a seguir, exemplifica a adição de uma coluna vl_tipo_atendimento NUMBER(8,2) na tabela TIPO_ATENDIMENTO:

FIGURA 26 | ALTERAR TABELA COM ADIÇÃO DE COLUNAS

A Figura a seguir, exemplifica a adição de uma coluna nm_estado_civil VARCHAR(25), na tabela PACIENTE:

Modificar colunas

ALTER TABLE nome-da-tabela

MODIFY (nome-da-coluna tipo-de-dado [(tamanho)]);

FIGURA 27 | ALTERAÇÃO DA TABELA COM MODIFICAÇÃO DE COLUNA

A Figura a seguir, exemplica a modificação da coluna nm_paciente, com aumento da quantidade de caracteres na tabela PACIENTE, para que seja VARCHAR(80):

Renomear colunas

ALTER TABLE nome-da-tabela

RENAME COLUMN coluna_antiga TO coluna_nova;

FIGURA 28 | ALTERAR A TABELA PARA RENOMEAR UMA COLUNA

A Figura a seguir, exemplifica como alterar a tabela MEDICO, renomeando coluna hr_medico para hr_trabalho:

Excluir colunas

ALTER TABLE nome-da-tabela

DROP COLUMN (nome-da-coluna);

FIGURA 29 | ALTERAÇÃO DA TABELA COM EXCLUSÃO DA COLUNA

A Figura a seguir, exemplifica a alteração da tabela MEDICO, excluindo a coluna hr_trabalho:

Adicionar restrições

ALTER TABLE nome-da-tabela

ADD CONSTRAINT nome-constraint tipo-constraint (campo-constraint);

FIGURA 30 | ALTERAR TABELA - ADICIONAR RESTRIÇÃO CHECK

A Figura a seguir, exemplifica a adição da restrição CHECK, para que aceite somente os tipos de estado civil listados com todas letras maiúsculas:

Truncar tabela (truncate table)

O comando TRUNCATE TABLE remove todas as linhas de uma tabela, liberando o espaço de armazenamento usado por essa tabela. Não podemos fazer rollback da linha ao usar TRUNCATE. Sintaxe:

TRUNCATE TABLE nome-da-tabela;

FIGURA 31 | TRUNCAR UMA TABELA

A Figura a seguir, exemplifica como truncar a tabela CLIENTE:

Renomear tabela (rename)

O comando RENAME permite alterar o nome de uma tabela, view, sequência ou sinônimo. Sintaxe:

RENAME nome_tabela_atual TO nova_tabela;

FIGURA 32 | RENOMEAR UMA TABELA

A Figura a seguir, exemplifica como renomear a tabela CLIENTE para BENEFICIARIO:

Excluir tabela (drop table)

O comando DROP TABLE exclui uma tabela. Ao tentar eliminar uma tabela do banco de dados, é feita uma verificação de dependências: caso existam tabelas que possuam FOREIGN KEY referenciadas à tabela que se deseja eliminar, esta não será eliminada. Observações: todas as transações pendentes sofrerão COMMIT. Todos os índices serão eliminados. Não é possível fazer ROLLBACK dessa instrução. Sintaxe:

DROP TABLE nome-da-tabela;

Atenção!

Quando eliminamos uma tabela, o banco de dados não libera imediatamente o espaço a ela associado. Em vez disso, o banco renomeia a tabela e a coluna em uma lixeira, onde podemos posteriormente recuperá-la. Para apagar a tabela definitivamente, utilize a palavra PURGE.

Para excluir uma tabela DEFINITIVAMENTE (expurgar), usamos o comando. Sintaxe:

DROP TABLE nome da tabela PURGE.

FIGURA 33 | EXCLUSÃO DE UMA TABELA

A Figura a seguir, exemplifica a exclusão da tabela BENEFICIARIO

Recuperar tabela (flashback table)

O comando FLASHBACK TABLE é uma instrução DDL, que restaura a tabela até o momento anterior, caso tenha sido apagada ou alterada erroneamente. Essa instrução restaura os registros de uma tabela, com os índices, atributos e views associados. Esse recurso não corrige erros físicos causados por uma HD ruim. Sintaxe:

FLASHBACK TABLE esquema.nome_tabela TO BEFORE DROP;

Saiba mais

RECYCLEBIN

A recyclebin é a lixeira onde ficam os objetos com seus registros excluídos.

Para consultar a recyclebin:

SELECT original_name, operation, droptime FROM recyclebin.

Obs.: podemos expurgar a lixeira com a instrução: PURGE RECYCLEBIN;

Mais informações disponível: https://www.devmedia.com.br/gerenciando-a-lixeira-no-oracle-10g/7895

Abrir pdf

FIGURA 34 | RECUPERAR UMA TABELA EXCLUÍDA

A Figura a seguir, exemplifica a recuperação da Tabela BENEFICIARIO:

Expurgar tabela (drop table purge)

O comando DROP TABLE ... PURGE permite expugar (excluir definitivamente sem direito à recuperação) uma tabela. Sintaxe:

DROP TABLE nome_tabela PURGE;

FIGURA 35 | EXPUGAR UMA TABELA (EXCLUIR DEFINITIVAMENTE)

A Figura a seguir, exemplifica como expurgar a tabela BENEFICIARIO:

Informações do objetos no banco de dados

Objetos pertencentes ao usuário logado: SELECT * FROM USER_OBJECTS;

Observações:

Pode utilizar o prefixo ALL para exibir todos os objetos do banco de dados.

Contém duas colunas o nome o tipo de todos os objetos;

Pode, também, utilizar como CATALOG: SELECT * FROM CAT;

Nome das tabelas existentes neste usuário: SELECT table_name FROM USER_TABLES;

Informações detalhadas das colunas de suas tabelas: SELECT * FROM USER_TAB_COLUMNS;

Obs.: para exibir mais de 80 caracteres na coluna do SQL * PLUS, digite o comando: SET LONG 1000.

A seguir, exemplos do acesso a essas informações:

FIGURA 36 | CONSULTA OS OBJETOS DE UM BD

FIGURA 37 | CONSULTA OS NOMES TABELAS DE UM USUÁRIO

FIGURA 38 | CONSULTA AS COLUNAS MANIPULADAS PELO USUÁRIO

FIGURA 39 | CONSULTA DETALHADA DAS COLUNAS

FIGURA 40 | CONSULTA O TIPO E O NOME DOS OBJETOS

Atenção!

Os nomes dos objetos nos bancos de dados são armazenados com letra maiúscula, independentemente de como foram criados.

Comentários de tabela

Podemos adicionar comentários a uma tabela ou coluna com o comando COMMENT. Sintaxe:

Acrescentar comentários na tabela:

COMMENT ON TABLE nome_tabela IS ‘texto’ ;

A Figura, a seguir, exemplifica comentário incluído na tabela ATENDIMENTO:

FIGURA 41 | INCLUIR COMENTÁRIO NA TABELA

Acrescentar comentários na coluna:

COMMENT ON COLUMN nome_tabela.nome_coluna IS ‘texto’;

A Figura, a seguir, exemplifica comentário incluído na coluna vl_atendimento da tabela ATENDIMENTO:

FIGURA 42 | INCLUIR COMENTÁRIO NA COLUNA DA TABELA

Para exibir os comentários, utilizamos as views do dicionário de dados que fornecem informações sobre os comentários existentes: SELECT * FROM <nome da view do dicionário de dados>;

Colunas que têm acesso: ALL_COL_COMMENTS;

Colunas do usuário: USER_COL_COMMENTS;

Tabelas que têm acesso: ALL_TAB_COMMENTS;

Tabelas do usuário: USER_TAB_COMMENTS.

A Figura a seguir, exemplifica os comentários existentes na tabela ATENDIMENTO:

FIGURA 43 | CONSULTAR OS COMENTÁRIOS EXISTENTES NAS TABELAS

A Figura a seguir, exemplifica os comentários existentes nas colunas da tabela ATENDIMENTO:

FIGURA 44 | CONSULTAR COMENTÁRIOS NAS COLUNAS DAS TABELAS

No curso DataBase Foundations, leia o capítulo "Data Definition Language (DDL)".

Saiba mais

'DataBase Foundations: Data Definition Language (DDL)'.

Abrir pdf

Data Manipulation Language (DML)

Os comandos da linguagem SQL classificamos como DML (Data Manipulation Language, ou Linguagem de Manipulação de Dados) são iniciados com as palavras reservadas: INSERT, DELETE, UPDATE, MERGE e SELECT.

Saiba mais

Linguagem SQL (comando UPDATE sem Where)

Link: https://www.youtube.com/watch?v=9hVnn-mFFMs

Recurso lista interativa:

Uma instrução DML é executada quando:

Conteúdo

Uma instrução DML é executada quando::

adiciona novas linhas a uma tabela;

modifica linhas existentes em uma tabela;

remove linhas existentes de uma tabela.

Voltar para a navegação do recurso lista interativa

Uma transação consiste em um conjunto de instruções DML que formam uma unidade lógica de trabalho. A manipulação de dados possui os seguintes comandos: INSERT, UPDATE e DELETE.

Inserir registros (insert into)

O comando INSERT INTO, permite inserir registros em tabelas. Sintaxe:

INSERT INTO tabela [(coluna), (coluna1)...] VALUES (valor, valor1,...);

FIGURA 45 | INSERÇÃO DE REGISTRO DE FORMA IMPLÍCITA

A Figura a seguir, exemplifica a inserção de registro na tabela de forma implícita, que são valores para todas as colunas existentes na tabela ESPECIALIDADE_MEDICA:

FIGURA 46 | INSERÇÃO DE REGISTRO DE FORMA EXPLÍCITA

A Figura a seguir, exemplifica a inserção de registro na tabela MEDICO de forma explícita, que são valores para as colunas informadas, sendo que são obrigatórias as colunas que fazem parte da chave primária e de preenchimento obrigatório (NOT NULL):

FIGURA 47 | INSERÇÃO DE REGISTRO COM VARIÁVEL DE SUBSTITUIÇÃO

A Figura a seguir, exemplifica a inseração de registro na tabela PACIENTE, usando variáveis de substituição:

Atualizar registros (update)

O comando UPDATE modifica linhas existentes. Atualiza mais de uma linha (registro) por vez, conforme a condição informada (se houver essa condição). Sintaxe:

UPDATE tabela

SET coluna = valor, [coluna1 = valor2, ...]

[WHERE condição];

FIGURA 48 | ATUALIZAÇÃO DE UMA COLUNA DE UM REGISTRO DA TABELA QUE ATENDE UMA CONDIÇÃO

A Figura a seguir, exemplifica a atualização das colunas nm_medico e cd_telefone de um registro na tabela MEDICO, com uma condição (cláusula WHERE):

FIGURA 49 | ATUALIZAÇÃO DE UMA COLUNA DE TODOS OS REGISTROS DA TABELA

A Figura a seguir, exemplifica a atualização de todos os registros da coluna vl_atendimento da tabela TIPO_ATENDIMENTO (não é usada a cláusula WHERE):

Excluir registros (delete)

O comando DELETE permite excluir registros (linhas) existentes de uma tabela que atenda a condição informada (se houver esta condição). Sintaxe:

DELETE [FROM] TABELA

[WHERE condição];

FIGURA 50 | EXCLUIR UM REGISTRO DA TABELA

A Figura a seguir, exemplifica a exclusão de um registro da tabela ATENDIMENTO com sg_atendimento = 'EXAME':

Inserção e atualização de registros (merge)

O SQL foi estendido de modo a incluir a instrução MERGE.

Quando usar essa instrução, podemos atualizar ou inserir uma linha condicionalmente em uma tabela, evitando várias instruções UPDATE.

A decisão referente à atualização ou inserção da tabela de destino se baseia em uma condição na cláusula ON. Este comando combina o INSERT e o UPDATE, por isto, precisamos possuir estes dois privilégios. Sintaxe:

MERGE INTO tabela apelido_tabela

USING (tabela|view|subconsulta) apelido

ON (condição_junção)

WHEN MATCHED THEN

UPDATE SET coluna1 = valor1, coluna2 = valor2,...

WHEN NOT MATCHED THEN

INSERT (coluna1, coluna2) VALUES (valor1, valor2,...);

Atenção!

Os comandos DML: INSERT, UPDATE, DELETE e MERGE, geram transação e por isso, ao término precisa ser confirmada ou cancelada esta transação.

CONFIRMAR TRANSAÇÃO: COMMIT;

CANCELAR TRANSAÇÃO: ROLLBACK;

No curso DataBase Foundations, leia o capítulo "Data Manipulation Language (DML)".

Saiba mais

DataBase Foundations: Data Manipulation Language (DML).

Abrir pdf

Data Transaction Language (DTL)

Uma transação é um conjunto de operações que caracterizam uma transformação no banco de dados, de um estado consistente para outro estado também consistente.

As operações, isoladamente, podem levar o banco de dados a estados transitórios inconsistentes. Temos que atender as características conhecidas pela sigla ACID (para mais informações leia o Saiba Mais).

Saiba mais

ACID sigla importante no banco de dados que caracteriza um CONTROLE DE TRANSAÇÃO significa: ATOMICIDADE, CONSISTÊNCIA, ISOLAMENTO e DURABILIDADE.

Atomicidade: Uma transação ou acontece totalmente ou não acontece. Para uma transação composta por várias operações, ou todas são registradas ou nenhuma o será. Ou seja, as instruções contidas em uma transação constituem em uma única unidade de trabalho;

Consistência: A execução de uma transação isolada preserva a consistência do banco de dados; É consistente quando uma transação começa e que ele termina em outro estado também consistente ao fina da transação acaba;

Isolamento: Quando diversas transações são executadas de forma concorrente, duas transações T1 e T2, sendo T1 mais antiga que T2, o resultado final é equivalente ao da execução total de T1 antes do início da execução de T2. As transações não são afetadas pelo processo concorrente; Resumindo: transações separadas não devem interferir uma com as outras.

Durabilidade: Os efeitos de uma transação perduram. Uma vez aceita, uma transação deve ter seus efeitos mantidos ao longo do tempo mesmo que haja falhas no sistema.

Após confirmado com COMMIT, as alterações são preservadas, mesmo que a máquina em que o software de bancos de dados está sendo executado falhe posteriormente.

A Figura a seguir, exemplifica o uso do COMMIT:

FIGURA 51 | USO DO COMMIT

A Figura a seguir, exemplifica o uso do ROLLBACK:

FIGURA 52 | USO DO ROLLBACK

Já vimos que os comandos DML (INSERT, UPDATE, DELETE e MERGE) precisam de confirmação de transação (COMMIT) ou cancelamento da mesma (ROLLBACK). O comando SAVEPOINT marca um ponto de salvamento na transação atual. Podemos ainda utilizar o comando ROLLBACK TO SAVEPOINT para efetuar o cancelamento da transação atual até o ponto de salvamento especificado, descartando, portanto, todas as alterações e/ou pontos de salvamento criados depois do ponto de salvamento especificado para o rollback. Se for omitida a cláusula TO SAVEPOINT, a instrução ROLLBACK será efetuado o rollback da transação inteira. Como estes pontos de salvamento são lógicos, não há como listá-los.

Passos

Faça um comando DML;

Crie um marcador em uma transação atual, usando a instrução SAVEPOINT;

Faça o cancelamento desse marcador, usando a instrução ROLLBACK TO SAVEPOINT.

Atenção!

Uma transação inicia com uma instrução DML (INSERT, UPDATE, DELETE ou MERGE).

É possível ter diversas instruções pendentes de confirmação e, ao confirmar, todas as transações pendentes são registradas no SGBD.

Confirmar a transação:

COMMIT;

Cancelar transações pendentes:

ROLLBACK.

Após confirmada a transação, não é possível cancelar. E caso haja transações pendentes e for feito qualquer comando DDL, automaticamente é confirmada a transação (COMMIT AUTOMÁTICO).

No curso DataBase Foundations, leia o capítulo "Data Transaction Language (DTL)".

Saiba mais

'DataBase Foundations: Data Transaction Language (DTL)'.

Abrir pdf

Para aprofundar seu conhecimento, confira a leitura indicada a seguir.

Estudo Guiado

Capítulo 8: “Manipulação de dados operação DML”. Leia as páginas 195 a 202.

Clique no link e leia o livro

PUGA, S.; FRANÇA, E.; GOYA M. Banco de dados: implementação em SQL, PL/SQL e Oracle 11G. São Paulo: Pearson, 2013.

Recuperação de dados (comando select)

Os dados armazenados em uma tabela podem ser recuperados (visualizados) de muitas maneiras.

O comando SELECT permite a seleção e a manipulação, para visualizar as informações armazenadas no banco de dados. Sintaxe:

SELECT [DISTINCT] {*, coluna [apelido],…}

FROM tabela;

Com esse comando, é possível exibir, conforme apresenta a Tabela:

TABELA 3 | OPÇÕES DE EXIBIÇÃO DAS INFORMAÇÕES (SELECT)

TIPODESCRIÇÃO

*Todas as colunas da tabela.

Colunas (campos) específicasOs nomes das colunas devem ser separados por vírgula.

Colunas com apelidos (alias)O apelido (título) que se deseja dar a uma coluna ou expressão deve aparecer logo após, delimitado por aspas duplas (' ').

Colunas concatenadasColunas ou expressões que terão seu resultado concatenado (unido). O operador (||) é responsável por essa funcionalidade.

ConstanteQualquer valor fixo que se deseje apresentar. Pode ou não ser acompanhado de alias. Para valores alfanuméricos e do tipo data, devem estar delimitados por aspas simples (').

DISTINCTLinhas duplicadas apareçam somente uma vez.

Expressões aritméticasPodem ser compostas das colunas das tabelas, constantes, funções, operadores aritméticos (+, -, / e *).

INSTITUCIONAL, 2022.

O comando SELECT possui, ainda, cláusulas distintas: WHERE, ORDER BY, GROUP BY e HAVING, que podem ser utilizados com operadores: lógicos, artiméticos e de comparação.

Operadores

Há os seguintes operadores, que trabalham com o comando SELECT: OPERADORES ARITMÉTICOS, OPERADORES DE COMPARAÇÃO e OPERADORES LÓGICOS.

Operadores aritiméticos

Os principais operadores aritméticos são *, /, + e -.

Obs.: use os parênteses para reforçar a ordem de precedência padrão e aumentar a compreensão.

Operadores de comparação

Os operadores de comparação são apresentados na Tabela a seguir.

TABELA 4 | OPERADORES DE COMPARAÇÃO

OPERADORDESCRIÇÃO

=Igual a

>Maior do que

>=Maior do que ou igual a

<Menor do que

<=Menor do que ou igual a

<> ou != ou ^=Diferente de

BETWEEN...ANDEntre dois valores (intervalo de valores)

IN (lista)Lista de valores

LIKEPadrão de caracteres

IS NULLÉ um valor nulo

INSTITUCIONAL, 2022.

Atenção!

OPERADOR LIKE

O operador LIKE utiliza caracteres especiais nas condições de pesquisa:

% representa um conjunto de caracteres.

_ cada underline representa um caractere.

Operadores lógicos

Os operadores lógicos são apresentados na Tabela a seguir:

TABELA 5 | OPERADORES LÓGICO

OPERADOR LÓGICODESCRIÇÃO

ANDRetorna TRUE se as condições de componentes forem TRUE (verdadeiro).

ORRetorna TRUE se pelo menos uma das condições de componente for TRUE (verdadeiro).

NOTRetorna TRUE se a condição seguinte for FALSE (falso).

INSTITUCIONAL, 2022.

REGRAS DE PRECEDÊNCIA

Todos os operadores de comparação, NOT, AND e OR.

Quando for necessário, forçar a prioridade utilizar parênteses.

Operador de concatenação

O operador de concatenação concatena colunas ou strings de caractere a outras colunas. É representado por duas barras verticais ( || )

Cria uma coluna resultante, que é uma expressão de caracteres.

String literal de caracteres

Um literal é um caractere (ou conjunto de caracteres), um número ou uma data incluída na lista do SELECT. Os valores literais de caractere e data devem estar entre aspas simples. Cada string de caractere é gerada uma vez para cada linha retornada. Sintaxe:

SELECT coluna || ' literal ' || coluna FROM tabela;

FIGURA 53 | EXIBIR TODOS OS REGISTROS DE UMA TABELA

A Figura a seguir, exemplifica a exibição de todos os registros e todas as colunas da tabela ATENDIMENTO:

FIGURA 54 | EXIBIR INFORMAÇÕES DAS COLUNAS LISTADAS DE UMA TABELA

A Figura a seguir, exemplifica a exibição das colunas nm_paciente e cd_cpf de todos os registros da tabela PACIENTE:

FIGURA 55 | EXIBIR LISTA EXCLUSIVA DE UMA COLUNA DA TABELA

A Figura a seguir, exemplifica uma lista exclusiva da coluna sg_atendimento de todos os registros da tabela ATENDIMENTO. Nesse exemplo, podemos interpretar para exibir as siglas de atendimentos realizados.

FIGURA 56 | CONSULTA COM APELIDO NAS COLUNAS

A Figura a seguir, exemplifica as colunas da tabela, colocando apelido (alias) 'Convenio' na coluna nm_razao_social da tabela CONVENIO:

FIGURA 57 | CONSULTA COM OPERADORES ARITMÉTICOS

A Figura a seguir, exemplifica a coluna vl_atendimento da tabela ATENDIMENTO, com o uso de operadores aritméticos:

Curiosidade

A consulta com operadores aritméticos é chamada PROJEÇÃO, pois exibe...

A consulta com operadores aritméticos é chamada PROJEÇÃO, pois exibe os possíveis valores calculados, sem alterar no banco de dados.

Restringindo e classificando dados (seleção)

Where

A cláusula WHERE restringe as linhas retornadas. A cláusula WHERE sempre segue a condição FROM. Sintaxe:

SELECT [DISTINCT] {*| coluna [apelido] ...}

FROM tabela

WHERE condição};

Atenção!

WHERE

A cláusula WHERE trabalha com os operadores OR e AND quando há mais de uma condição a ser atendida e em junção de tabelas.

FIGURA 58 | EXIBIR OS REGISTROS COM A CLÁUSULA WHERE

A Figura a seguir, exemplifica a consulta com a clausula WHERE exibindo todas as informações da tabela PACIENTE com cd_cpf maior ou igual a 105:

FIGURA 59 | CONSULTA COM A CLÁUSULA WHERE E OPERADOR AND

A Figura a seguir, exemplifica o uso do WHERE e AND, exibindo todas as informações da tabela ATENDIMENTO com cd_cpf = 105 e sg_atendimento = 'CONSU'. Obs.: as duas condições devem ser verdadeiras, para que haja rsultado:

FIGURA 60 | CONSULTA COM AS CLÁUSULAS WHERE E OR

A Figura a seguir, exemplifica o uso do WHERE e OR, exibindo todas as informações da tabela ATENDIMENTO, realizadas pelos médicos com cd_crm = 3334 ou cd_crm = 2223. Obs.: uma das duas condições devem ser verdadeiras, para que haja rsultado:

FIGURA 61 | CONSULTA COM USO DA CLÁUSULA WHERE E O OPERADOR BETWEEN

A Figura a seguir, exemplifica o uso do WHERE e BETWEEN, exibindo todas as informações da tabela PACIENTE, com cd_cpf de 101 a 105:

FIGURA 62 | CONSULTA COM A CLÁUSULA WHERE E O USO DO OPERADOR IN

A Figura a seguir, exemplifica o uso do WHERE e operador IN, exibindo todas as informações da tabela ATENDIMENTO, com cd_crm 3334 ou 2223:

FIGURA 63 | CONSULTA COM A CLÁUSULA WHERE E O USO DO OPERADOR NOT

A Figura a seguir, exemplifica o uso do WHERE e do operador NOT, exibindo todas as informações da tabela PACIENTE, com cd_cpf de 101 a 105:

Atenção!

O operador NOT negativa um operador. Ou seja, pode aparecer antes dos operadores: IN, BETWEEN, LIKE IS e NULL.

FIGURA 64 | CONSULTA COM CLÁUSULA WHERE E OPERADOR LIKE COM CARACTERE %

A Figura a seguir, exemplifica o uso do WHERE e operador LIKE com o caractere %, exibindo o nome dos médicos que iniciam com a letra G da tabela MEDICO:

FIGURA 65 | CONSULTA COM CLÁUSULA WHERE E OPERADOR LIKE COM CARACTERES ESPECIAIS _ E %

A Figura a seguir, exemplifica o uso do WHERE e do operador LIKE com os caracteres _ (cada underline representa um caractere) e % (esse caractere representa um conjunto de caracteres), e o caractere _ (cada underline representa um caractere) exibindo o nome dos pacientes da tabela PACIENTE cujo nome inicia com qualquer letra e tenha uma letra e minúscula na segunda posição do nome:

FIGURA 66 | CONSULTA COM CLÁUSULA WHERE E O OPERADOR IS NULL

A Figura a seguir, exemplifica o uso do WHERE e do operador IS NULL, para exibir os regisgtros da tabela MEDICO que não possuem cd_telefone:

Order by

A cláusula ORDER BY classifica as linhas com a cláusula ORDER BY:

ASC – ordem crescente (default), não precisa ser acrescentada;

DESC – ordem decrescente.

Atenção!

ORDER BY

A cláusula ORDER BY é a última cláusula em uma instrução SELECT.

É possível ordenar com mais de uma coluna, separando por vírgula.

FIGURA 67 | CONSULTA COM ORDENAÇÃO DE FORMA ASCENDENTE

A Figura a seguir, exemplifica o uso do ORDER BY de forma ascendente (padrão do ORDER BY, e não é necessário colocar a palavra reservada ASC) pela coluna nm_paciente da tabela PACIENTE:

FIGURA 68 | CONSULTA COM ORDENAÇÃO DE FORMA DESCENDENTE

A Figura a seguir, exemplifica o uso do ORDER BY de forma descendente (usamos a palavra reservada DESC) pela coluna vl_atendimento da tabela ATENDIMENTO:

No curso DataBase Foundations, leia o capítulo "Recuperação de Dados (SELECT)".

MODELAGEM DE SOFTWARE

Inhalt der Notizen (10)

Seite 1

Calendário

AVALIAÇÕES

Critérios

Seite 2

INTRODUÇÃO (DL)

Seite 3

ESPECIFICAÇÃO DE REQUISITOS TRADICIONAIS

Requisitos funcionais

Requisitos não funcionais

Principais características

Problemas comum nos requisitos

Classes de requisitos

Requisitos de domínio

Documentação de requisitos

Seite 4

TÉCNICAS DE LEVANTAMENTO DE REQUISITOS

Seite 5

ESPECIFICAÇÃO DE REQUISITOS ÁGEIS

Seite 6

COMPREENDER E PROJETAR BANCO DE DADOS

Seite 7

MODELO CONCEITUAL DE DADOS

Seite 8

MODELO LÓGICO DE DADOS

Seite 9

DIAGRAMAS UML

Seite 10

MODELO FÍSICO DE DADOS

Informationen

Feedback

Wie gefällt dir das neue Design?