A principal causa para esta situação é a ideia que menos elementos, acarretam menos custos. No imediato esta suposição pode ser verdade, mas a médio e longo prazo não. A equipa de DBAs com excesso de trabalho, pode cometer erros e constrangimentos de operação e de manutenção que originem custos superiores ao salário de vários elementos da equipa de DBAs.

Esta mensuração não é uma ciência exacta e depende muito do ambiente envolvente: 

• Os SLAs, quanto mais restrito é o nível de serviço, mais exigente é para a equipa de DBAs a efectivação do mesmo. Existem situações em que as respostas das base de dados (resultados das instruções de SQL) é na casa dos milésimos de segundo e esta é uma situação mais difícil de garantir suporte, manutenção e administração do que a base de dados com SLAs em que as respostas (resultados das instruções de SQL) é na casa dos segundos, também o cumprimentos das melhores práticas recomendadas pelo ITIL no suporte a base de dados (incident Management, problem Management, configuration Management, change Management, release Management) e uma gestão de serviço prestado pela DBA BOX pressupõe um controlo das operações, onde é necessário possuir o número de elementos que garantam o seu cumprimento.

• Os requisitos de desempenho, quanto maiores forem as necessidades de desempenho das bases de dados mais exigente é o seu suporte, manutenção e administração.

• A experiência, competência e empenho individual de cada elemento da equipa de DBAs é muito importante no dimensionamento da equipa.

• O impacto da indisponibilidade, quanto maior o custo monetário e de imagem do cliente numa indisponibilidade, maior será a pressão na equipa de DBAs e na suas operações.

• O número de SGBDR, o número de base de dados associadas e a sua dimensão, o número de utilizadores, número de processos suportados e a sua tipologia, influência bastante o número de elementos necessário na equipa de DBAs. É necessário realizar manutenção, administração, validar cópias de segurança, produzir documentação, planear a melhoria contínua, garantir a disponibilidade e o desempenho das bases de dados, melhorar instruções de SQL.

• No caso das equipas de desenvolvimento não possuírem as competências suficientes no desenvolvimento de instruções de SQL complexo, é necessário que existe essa competência no seio da equipa de DBA para melhorar o desempenho das instruções de SQL.

Como alguém já disse é só fazer a conta e obtêm o resultado, neste caso o número de elementos das equipas de DBAs (DBA BOX).

João Paulino

O BRIEFING é uma reunião de informação táctica antecedente à partida para uma missão aérea na qual participam os PILOTOS AVIADORES, onde é explicado o conteúdo da missão, as manobras a realizar e os objectivos a atingir.

O DEBRIEFING é uma reunião em que participam os PILOTOS AVIADORES após a missão aérea, onde são analisados e aferidos os resultados da missão, respectivas manobras e se detectam os aspectos a serem especificamente melhorados.

O “VOO de cadeira” é um treino de preparação onde os PILOTOS AVIADORES simulam todas a manobras e movimentos que vão executar na missão, como se de um voo real se tratasse.

Para assegurar uma elevada proficiência nas suas intervenções as DBA BOX, tal como os PILOTOS AVIADORES asseguram nas suas missões, aquelas devem realizar BRIEFING/DEBRIEFING e “VOO de cadeira“.

O “VOO de cadeira” será um treino de preparação onde o elemento ou os elementos da DBA BOX simulam em ambiente de teste, todos os passos das acções a realizar num ambiente de produção de base de dados.

O BRIEFING será a reunião, onde são alinhados os pormenores da intervenção, revisto o plano e os seus objectivos.

O DEBRIEFING é uma reunião, onde são analisados e aferidos os resultados da intervenção, respectivas acções e se detectam os aspectos a serem melhorados.

No meio militar a falha tem um preço muito alto, falhar ou não, pode ser a diferença entre a vida e morte.

João Paulino

A atitude egocêntrica, desalinhada e reactiva que cerca de 90% das DBA BOXs que prestam apoio de administração e manutenção de base de dados em Portugal, é uma das causas, senão a maior de problemas e incidentes, que acontecem em base de dados.

É completamente errada a postura de dificultar os processos de negócio do cliente, de ser resistente a mudanças. Assiste-se a comportamento errados na demora de realizar tarefas/acções com elevado grau de maturidade com o intuito do cliente sentir na pele a necessidade e dependência que têm da DBA BOX. A ausência de análise e gestão de risco na maioria das acções realizadas, falta de planos de continuidade são exemplos da fraca qualidade na tentativa de prestar um serviço.

Ainda pior é a forma de agir em “Cartel” que algumas DBA BOXs apresentam. Não é nada raro o cliente saber que um dos seus sistemas apresenta lentidão, proceder à detecção da causa, ser informado pelos administradores de sistema que os HOSTs que suportam as base de dados se encontram com carga elevada (seja CPU ou I/O) e quando a DBA BOX é contactada, informa que não há qualquer lentidão ou carga nas bases de dados. Neste tipo de BDA BOX não existe responsabilidade, idoneidade, proficiência, enfim reina a falta de profissionalismo. Quem não sabe é como quem não vê, quantas vezes a DBA BOX não tem sequer a percepção real do seu comportamento e as consequências nos processos do cliente e do seu negócio.

Afaste os seus sistemas de base de dados deste tipo de DBA BOXs e fuja deles como o diabo foge da cruz.

A DBA BOX não é mais uma ilha isolada no IT, onde ninguém consegue aceder, para onde as comunicações são difíceis e os seus habitantes são hostis e não colaborativos.

É necessário criar pontos de comunicação e acesso à ilha da DBA BOX, alinha-la com metodologias Agile e regê-la pelas recomendações do ITIL apoiada por ITSM. É um enorme passo no sentido de fazer com que seja proficiente, responsável, proactiva, colaborativa e alinhada com o seu cliente.  É forma correcta de obter, gerir e melhorar o nível e qualidade esperada do serviço.

João Paulino

Como resultado da actual crise ou por simples falta de recursos humanos e ainda sobre o capa da redução de custo a que os departamentos de TI se encontram sujeitos, estes recorrem a préstimos de DBA BOX externas. Não me parece uma opção descabida, no entanto há que ter cautela, e porquê? Bom, vou tentar explicar e abordando as diferentes vertentes na gestão de serviços da DBA BOX associada a práticas “ITSM/ITIL” e metodologias “Agile”.

Será que os elementos da DBA BOX são suficientes para trocar a sua lâmpada?

O que quero perguntar é se DBA BOX possui recursos suficientes para garantir a correcta e eficiente administração e manutenção do conjunto de base de dados a seu cargo, e nos sistemas considerados críticos uma disponibilidade operacional contínua numa base 24 X 7.

Quais as normas, e processos que a DBA BOX está sujeita e deve cumprir?

Qual é a garantia que são cumpridos todos os procedimentos, que as cópias de segurança são fiáveis e encontram-se em condições de serem utilizadas, as regras de segurança, confidencialidade estão a ser contempladas?

Os dados mais críticos e sensíveis estão a salvo de acções de má fé ou de espionagem?

Qual o método e métricas de avaliação de desempenho de cada elemento da DBA BOX?

A qualquer momento sabe-se quem é o recurso responsável por determinada intervenção? Ou estão encapsulados na DBA BOX? Recursos eficazes, correctos e com brio profissional têm nome e constroem um portfólio.

Quem é que controla, verifica e auditas as acções da DBA BOX?

Cerca de 75% dos problemas com base de dados são originados por erro humano. Uma parte por negligência ou desleixo, mas a maioria por falta de proficiência. As coisas más acontecem, e acontecem de um modo muito fácil e rápido!

Além de prometer que se fornece um nível de serviço da DBA BOX, é necessário garantir e efectivar essa promessa. Para se alcançar esse objectivo é necessário gerir a DBA BOX de forma alinhada com as necessidades e perspectiva do cliente em deternimento do tecnológico. Reduzir os custos e entregar valor ao negócio, migrar de uma prática de perspectiva tecnológica para uma prática de serviço.

É imprescindível retribuir condignamente o cumprimento dos requisitos e expectativas do cliente e do seu negócio ao nível da qualidade do serviço da DBA BOX, aquele deverá ser capaz de avaliar e mesurar a contribuição do serviço da DBA BOX na cadeia de valor do seu negócio. Para obter essa métrica deve-se colocar o cliente a participar na avaliação contínua e no entendimento do serviço da DBA BOX e as suas expectativas futuras do mesmo e preparação para os desafios empresariais do cliente.

O objectivo do PCDA ou ciclo de Deming é tornar claros e ágeis os processos envolvidos na gestão, neste caso na gestão de qualidade do serviço da DBA BOX e divide-se em quatro passos:

 - Planear

 - Executar

 - Verificar

 - Agir

 Fase 1. Planear (PLAN)

Esta fase é desenvolvida tendo como base as necessidades e orientações do cliente e do seu negócio. Quando é iniciada esta fase deve ter em consideração 3 pontos importantes:

                – Determinar os objectivos, incidindo nos itens de controlo.        

                – Estabelecer e o percurso para atingir os objectivos.

                – Seleccionar pelos métodos a utilizar para alcançar os objectivos.

Após decidir os objectivos, recorre-se a uma metodologia correcta para alcançar os resultados pretendidos.

Fase 2. Executar o Plano(DO)

                – Treinar para alcançar a proficiência na metodologia a ser utilizada.

                – Executar o processo cumprindo o método.

                – Recolher a informação pertinente para verificação e validação do processo.

As tarefas devem ser executadas exactamente e cumprindo os planos.

Fase 3. Verificar os resultados do Plano Executado (CHECK)

                – É durante esta fase que são validados os processos e avalia-se os resultados obtidos:

                – Verificar se as acções foram realizadas de acordo com o padrão.

                – Comparar os valores/resultados com o padrão/norma/boas práticas.

Aferir se os itens de controlo correspondem aos dos objectivos.

Fase 4. Realizar acções correctivas ao Plano Executado e Verificado(ACT)

                – Estas acções devem ser baseadas nos resultados da fase 3.

                – Se os resultados se desviarem do padrão, iniciar as acções necessárias para os corrigir.

                – Caso se encontrem fora do padrão, deve-se investigar a causa ou origem e providenciar acções de prevenção e correcção.

Melhorar de forma continuada o processo de trabalho e o método.

A DBA BOX Ágil encontra-se envolvida e comprometida com a segurança, disponibilidade, confidencialidade, evolução e comportamento dos dados numa ou várias Base de Dados. Para além das competências técnicas tradicionais de administração, programação, modelação de dados, realização de testes, etc, deverá possuir conhecimentos sobre os processos de software, bem como competências que lhe permitam uma colaboração efectiva com profissionais de outras BOX’s, por exemplo: equipas de desenvolvimento, arquitectos e engenheiros de  Base de Dados, para esta colaboração a DBA BOX deverá possuir conhecimentos gerais de OOP, UML entre outras. A acção da DBA BOX deverá ser evolutiva e interactiva e tem que adaptar-se ao modernos processos de desenvolvimento (i.e.: Unified Process  ou XP).

João Paulino

Database Architect 

João Paulino

Nota: Projecto alterado, aguardem as novidades!!!

João Paulino

 Responsabilidades, características, especialização, formação e tarefas do Arquitecto de Base de Dados.

• 1. Analisar e compreender de forma relevante;
  • 1.1.1. Especificações dos requisitos.
  • 1.1.2. Convenções.
  • 1.1.3. Documentação de Administração dos produtores de SGBDR’s.
• 2. Arquitectura de Base de Dados;
  • 2.1.1. Avaliar requisitos de relevância/impacto sobre as Bases de Dados.
  • 2.1.2. Realizar o planeamento de capacidade das Bases de Dados.
  • 2.1.3. Assegurar que a arquitectura do sistema e do software abordam devidamente a persistência.
  • 2.1.4. Determinar a tecnologia de Dados adequada (i.e., relacional ou objecto)
  • 2.1.5. Avaliar e seleccionar os SGBDR’s a serem incorporados nas aplicações de software.
  • 2.1.6. Determinar onde as Bases de Dados serão disponibilizadas em sistemas de aplicações distribuídas multi-camadas (i.e., Bases de Dados Relacionais em Servidores Dedicados de Base de Dados, Base de Dados de Objectos na middle tier e Base de Dados Relacionais na camada de backend da infrastrutura).
  • 2.1.7. Avaliar e seleccionar correctamente e de modo apropriado os equipamentos de armazenamento (NAS, DAS, SAN e Robot’s de Tape para Backup).
  • 2.1.8. Produzir os modelos lógicos para as Bases de Dados.
  • 2.1.9. Determinar se o software de acesso à Base de Dados necessita modificações.
  • 2.1.10. Colaborar com outros profissionais para determinar:
    • 2.1.10.1. O impacto das alterações da Base de Dados nos outros sistemas.
    • 2.1.10.2. O custo ao nível de recursos humanos para alteração nas Base de Dados.
  • 2.1.11. Especifica as autorizações dos utilizadores:
    • 2.1.11.1. Quais os utilizadores que acedem a determinada Base de Dados.
    • 2.1.11.2. A que Dados os utilizadores acedem em determinada Base de Dados.
  • 2.1.12. O nível de acesso aos Dados (i.e., create, select, update, delete)
  • 2.1.13. Avaliar de forma adequada a plataforma que suporta as Base de Dados.
  • 2.1.14. Providenciar/Normalizar modelos de código fonte:
    • 2.1.14.1. Acesso a Base de Dados.
    • 2.1.14.2. Stored Procedures, Views, Functions, Triggers.
  • 2.1.15. Produzir os itens relacionados com a Base de Dados nas áreas do desenvolvimento/implantação e operações:
    • 2.1.15.1. Plano de Implantação.
    • 2.1.15.2. Manual de Instalação.
    • 2.1.15.3. Manual de Operações.

Perfil

Para cumprir esta função, o profissional Arquitecto de Base de Dados deverá possuir as seguintes características pessoais, conhecimentos técnicos, formação e experiência.

• 1. Características pessoais;
  • 1.1.1. Pensamento lato e abstracto que permita:
    • 1.1.1.1. Trabalhar confortavelmente e estrategicamente num alto nível de abstracção
    • 1.1.1.2. Ter uma visão geral sem pormenores supérfluos.
    • 1.1.1.3. Ter uma visão para além dos evidentes problemas e possíveis conexões entre os mesmo que pareçam não estar relacionados.
    • 1.1.1.4. Capacidade de reconhecer questões essenciais subjacentes a situações complexas.
  • 1.1.2. Capacidade de realizar e aplicar a engenharia nas seguintes situações:
    • 1.1.2.1. Requisitos que provoquem conflitos significativos na arquitectura.
    • 1.1.2.2. Decisões que envolvam competição por persistência, especialmente as Bases de Dados.
  • 1.1.3. Capacidade de identificar requisitos arquitectónicos e suas ramificações na arquitectura das Base de Dados.
  • 1.1.4. Capacidade de captar de uma forma clara e inequívoca o contexto da aplicação e da arquitectura do sistema, em particular base de dados herdadas.
  • 1.1.5. Capacidade de estimar e projectar a actual e futura dimensão:
    • 1.1.5.1. Da Base de Dados (i.e., média e número máximo de tabelas/classes e registos/objectos).
    • 1.1.5.2. Hardware necessário (i.e., número e dimensão dos servidores de Base de Dados, Discos de Storage e Sistemas de Backup)
  • 1.1.6. Capacidade de realizar confortavelmente tarefas de arquitectura em simultâneo.
  • 1.1.7. Capacidade de tomar importantes decisões, mesmo com informação incompleta ou em conflito.
  • 1.1.8. Alta capacidade de gerir e prioritizar os múltiplos desafios em simultâneo e concorrentes, tais como: questões, ambiguidades e contradições que são normais ocorrerem durante o processo de desenho e arquitectura das Base de Dados.
  • 1.1.9. Capacidades consolidadas na análise e resolução de problemas.
  • 1.1.10. Excelentes capacidades de comunicação verbais e escritas, capacidade de explicar e documentar a arquitectura da Base de Dados a diversas audiências
  • 1.1.11. Sólidas competências de construção e motivação de equipas.
• 2. Especialização;
  • 2.1.1. Conhecimentos aprofundados e práticos:
    • 2.1.1.1. Tarefas, técnicas e ferramentas de arquitectura de Base de Dados.
    • 2.1.1.2. Modelação lógica e física de Dados.
    • 2.1.1.3. Teoria de modelação de Base de Dados, incluí normalização de dados, replicação de dados, integridade de dados e segurança de dados.
    • 2.1.1.4. Desenvolvimento baseado em componentes, conceitos, modelos, infra-estrutura e interfaces.
    • 2.1.1.5. Tecnologias de infra-estrutura e de integração de sistemas utilizadas para implementar as arquitecturas de sistemas, conhecimento dos fabricantes e produtos disponíveis.
    • 2.1.1.6. Como desenvolver e implementar arquitecturas para aplicações distribuídas e acedida por várias plataformas heterogéneas.
    • 2.1.1.7. Conceitos de Object-oriented (OO), como Abstracção, Encapsulação, Herança e polimorfismo.
    • 2.1.1.8. Linguagens de Modulação (i.e., UML, OML, Modelação E-R, ) incluído a capacidade de produzir e interpretar os documentos e diagramas associados.
    • 2.1.1.9. Ferramentas de modelação de Base de Dados.
    • 2.1.1.10. Standards e orientações gerais de Arquitectura.
  • 2.1.2. Sólidos conhecimentos:
    • 2.1.2.1. Teóricos e práticos de ferramentas de Administração de Base de Dados.
    • 2.1.2.2. Principais padrões e mecanismos de persistência reutilizáveis.
    • 2.1.2.3. Modelos de arquitecturas de Base de Dados para aplicações específicas ou famílias de aplicações.
    • 2.1.2.4. Mecanismos de segurança das Base de Dados.
    • 2.1.2.5. Conceitos e técnicas de Engenharia.
    • 2.1.2.6. Objectos, casos de uso, processos e modelagem funcional.
    • 2.1.2.7. Arquitectura de Hardware e Software.
    • 2.1.2.8. Redes e equipamentos de rede.
    • 2.1.2.9. Conhecimentos teóricos e práticos de ferramentas de Engenharia de Software.
    • 2.1.2.10. Conhecimentos Básicos:
      • 2.1.2.10.1 Domínio da Aplicação.
      • 2.1.2.10.2 Negócio da Empresa cliente.
    • 2.1.2.11. Conhecimentos teóricos e práticos de ferramentas de testes e integração.
    • 2.1.2.12. Ferramentas de gestão de configurações, controlo de configurações.
• 3. Formação;
  • 3.1.1. Bacharelato, licenciatura ou outro ciclo superior de estudos em Engenharia Informática, Engenharia Informática e de Sistema, Engenharia de Sistemas e Informática, Engenharia Informática e de Computadores, Engenharia Electrotécnica e de Computadores, Informática, Matemática Informática ou equivalente.
  • 3.1.2. Formação Profissional dos fabricantes de SGBDR’s (i.e., Oracle, Microsoft, IBM, MySQL, etc.)
  • 3.1.3. Prática em:
    • 3.1.3.1. Projectos, tarefas relevantes, técnicas, produtos.
    • 3.1.3.2. Ferramentas, conceitos e diagramas de modelagem de Dados.
    • 3.1.3.3. SGBDR’s.
    • 3.1.3.4. Técnicas e Conceitos de Data Warehouse
    • 3.1.3.5. Auto-formação e actualização na leitura de livros, revistas e artigos da especialidade.
• 4. Tarefas;
  • 4.1.1. Arquitectura de persistência e Base de Dados:
    • 4.1.1.1. Seleccionar os padrões da Arquitectura.
    • 4.1.1.2. Concepção da Arquitectura lógica.
    • 4.1.1.3. Concepção da Arquitectura Física.
    • 4.1.1.4. Concepção do Mecanismo da Arquitectura.
    • 4.1.1.5. Reutilização da Arquitectura
    • 4.1.1.6. Documentação da Arquitectura.
    • 4.1.1.7. Garantia da Integridade da Arquitectura.
    • 4.1.1.8. Ambientes de Engenharia, incluí fornecedores SGBDR’s.
    • 4.1.1.9. Avaliação de SGBDR’s
    • 4.1.1.10. Selecção de SGBDR’s.
    • 4.1.1.11. Implementação;
      • 4.1.1.11.1. Planeamento da implementação.
  • 4.1.2. Operações;
  • 4.1.2.1. Documentação das Operações, incluí:
    • 4.1.2.1.1. Documentação incluindo operações: (tarefas operacionais de administração de Base de Dados, tarefas Operacionais, tarefas de instalação de Base de Dados e software associado).
  • 4.1.3. Engenharia da Qualidade;
    • 4.1.3.1. Controle de Qualidade – Avaliação de requisitos.
    • 4.1.3.2. Inspeccionar e avaliar o desenho da Base de Dados.
  • 4.1.4. Documento do design da Base de Dados.
  • 4.1.5. Componente de Software.
  • 4.1.6. Garantia de Qualidade – Auditoria do Desenvolvimento da Base de Dados.
  • 4.1.7. Técnicas, tarefas relacionadas com a Base de Dados.
  • 4.1.8. Standards, modelos, validação e verificação do documento de design da Base de Dados.

João Paulino

CDC (Change Data Capture) é uma das novas e interessantes funcionalidades que chegou ao SQL Server (alguns de nós já a conhecíamos do ORACLE), permite detectar alterações (INSERT, DELETE, UPDATE) relativamente aos dados de uma tabela e replicá-las noutra tabela, sem recorrer aos tradicionais triggers ou outras metodologias mais rebuscadas.

MS SQL Server 2008 CDC

Link

João Paulino

REVISIONS:
Ver DATE Author Description
——— ———- ————— ————————————
1.0 João Paulino 1. Created this Program.

NOTES:
OBJECT NAME:
DATE AND TIME:
Username:

******************************************************************************/
#include <stdio.h>
#include <conio.h>
#include <ctype.h>

void main (void)
{
int i, j, k;
char opt; // declarar variável para controlo da repetição da execução do programa
do // ciclo que controla a repetição da execução do programa
{
printf (“\nDigite um número [1-9] e pressione enter:”); // Mensagem para o utilizador digitar um número
if (scanf(“%d”, &k) == 1) // atribuir o valor digitado à variável n e validar se é do tipo inteiro if(valor)==1)
{
if (k > 9 ) // verificar a condição k não pode ser maior do que 9
printf(“O inteiro %d digitado não permite aplicar o algoritmo\n “,k); // Mensagem para o utilizador indicando que não é possível aplicar o algoritmo
else // caso se verifique a condição k <= 9
{
for (i = k; i >= 1; i–)
{
for (j= i+1 ; j <= k; j++)
printf(” “);
for (j = 1; j <= i; j++)
printf(“%d”, j);
for (j = i-1; j >=1; j–)
printf(“%d”, j);
printf(“\n”);
}
}
}
else // não foi digitado um número
{
printf (“\nNão digitou um algarismo ou número!!!”); // Mensagem para o utilizador a informar que não foi digitado um número
}

fflush(stdin); // escreve para o stream indicado qualquer dado armazenado, limpando-o

printf (“\nDeseja continuar? (S/N):”);

do
{
opt = toupper(getchar()); // recebe a entrada digitada e converte-a em maiúscula para facilitar

if ((opt != ‘S’) && (opt != ‘N’)) // caso a entrada não seja S ou N
putch(7); // faz soar o sino

} while ((opt != ‘S’) && (opt != ‘N’)); // repete a captura da opção enquanto a condição for verdadeira
} while (opt != ‘N’); // repete o programa enquanto a condição for verdadeira
} // fim da função main

João Paulino

REVISIONS:
Ver DATE Author Description
——— ———- ————— ————————————
1.0 João Paulino 1. Created this Program.

NOTES:
OBJECT NAME:
DATE AND TIME:
Username:

******************************************************************************/
#include <stdio.h>
#include <conio.h>
#include <ctype.h>

void main (void)
{
int i, j, k;
char opt; // declarar variável para controlo da repetição da execução do programa
do // ciclo que controla a repetição da execução do programa
{
printf (“\nDigite um número [1-9] e pressione enter:”); // Mensagem para o utilizador digitar um número
if (scanf(“%d”, &k) == 1) // atribuir o valor digitado à variável n e validar se é do tipo inteiro if(valor)==1)
{
if (k > 9 ) // verificar a condição k não pode ser maior do que 9
printf(“O inteiro %d digitado não permite aplicar o algoritmo\n “,k); // Mensagem para o utilizador indicando que não é possível aplicar o algoritmo
else // caso se verifique a condição k <= 9
{
for (i = 1; i <= k; i++)
{
for (j= i+1 ; j <= k; j++)
printf(” “);
for (j = 1; j <= i; j++)
printf(“%d”, j);
for (j = i-1; j >=1; j–)
printf(“%d”, j);
printf(“\n”);
}
}
}
else // não foi digitado um número
{
printf (“\nNão digitou um algarismo ou número!!!”); // Mensagem para o utilizador a informar que não foi digitado um número
}

fflush(stdin); // escreve para o stream indicado qualquer dado armazenado, limpando-o

printf (“\nDeseja continuar? (S/N):”);

do
{
opt = toupper(getchar()); // recebe a entrada digitada e converte-a em maiúscula para facilitar

if ((opt != ‘S’) && (opt != ‘N’)) // caso a entrada não seja S ou N
putch(7); // faz soar o sino

} while ((opt != ‘S’) && (opt != ‘N’)); // repete a captura da opção enquanto a condição for verdadeira
} while (opt != ‘N’); // repete o programa enquanto a condição for verdadeira
} // fim da função main

João Paulino