Estrutura com alguns componentes em um SI com ênfase para os componentes de BD

Prévia do material em texto

Figura 1.1 – Estrutura com alguns componentes em um SI com
ênfase para os componentes de BD
Fonte: Elaborada pelo autor.
Os dados dos bancos de dados estão organizados e estruturados
conforme um modelo de dados, no caso um dos tipos de modelo, o Modelo
Relacional foi ilustrado. Essa arquitetura é comumente chamada de
arquitetura cliente-servidor, pois um determinado sistema-cliente que
precisa de um certo serviço, no caso para o trato de dados, dispara as
requisições para um servidor responsável por prover o serviço. Ela não é
exclusiva para dados, visto que esses mesmos conceitos podem ser
usados para outros serviços, como navegação na internet por meio de
requisições a servidores Web (HTTP) ou a leitura de mensagens enviadas
e recebidas por meios de servidores de correio eletrônico (e-mail). Vale
ainda destacar que outras arquiteturas mais complexas e outros
componentes podem ser empregados. O propósito nesse momento fica na
compreensão desses conceitos simples de arquitetura cliente-servidor e
será base para os assuntos subsequentes de sistemas gerenciadores de
bancos de dados.
Mas tranquilo quanto a que vocês não estão gostando como eu faço meu trabalho, mas se
trata de uma tabela direcionando os os clientes ao seu produto, mas vou mandar algumas
ponderações:
Modelo Relacional, Exemplo de Tabela
O Modelo entidade relacionamento proposto por Peter P. Chen pode ser melhor
compreendido por uma teoria chamada de A lei do Mundo, teoria essa, que
conceitua que o mundo está cheio de coisas que possuem características próprias e
que se relacionam entre si. Sua analise da teoria pode ser dividida em três partes.
O mundo está cheio de coisas
Tudo que possa ser caracterizado, conceituado, real ou imaginário, no nosso
Universo (Mundo), é definido como coisa, que futuramente, dependendo da
abordagem, poderá ser definido como uma entidade.
Que possuem características próprias
Características comuns percebidas entre as coisas de modo que haja a possibilidade
de enquadramento dessas coisas em conjuntos particulares. Exemplo: “conselho de
economia, conselho de medicina, conselho de odontologia” todos podem ser
enquadrados em um mesmo conjunto, denominado como Órgão normalizador.
E que se relacionam entre si
São as relações entre as coisas. Como as mesmas irão relaciona-se entre elementos
individualizados de diferentes conjuntos ou entre elementos de um mesmo
conjunto. A forma de comunicação entre as coisas ou um conjunto delas,
Exemplos: Adail é credenciado pelo conselho de economia é um relacionamento
entre elementos de diferentes conjuntos. Adail é substituto de Caio é um
relacionamento entre elementos do mesmo conjunto.
Objeto de Dados ou Entidade
É a representação genérica de um componente do mundo real, sobre o qual
desejamos armazenar informações, uma representação de quase todas as
informações com varias propriedades que devem ser compreendidas pelo sistema
de informação, qualquer coisa que produza ou consuma informações. Entidade são
coisas significativas sobre a qual a organização deseja guarda, ou seja, (coletar,
manter e etc) dados podendo ser algo tangível ou intangível.
Ex.: Cliente; Produto; Contrato de Operação
Vários autores defendem formas de identificar e classificar as entidades, onde suas
tipificações mais comuns são:
● Coisas tangíveis: todos os elementos que tenham existência concreta.
Fisicamente existente. Ex: Produto, animal, carro.
● Funções: todo o tipo de papel, atribuição, classificação, capacitação, ou
outra característica que especifique atuação. Ex: Cliente, professor,
departamento.
● Eventos ou ocorrências: só conseguem ser percebidos ou caracterizados,
enquanto uma certa ação se desenrola. Ex: Lançamento em conta corrente.
Nomenclatura e Dicionarização
Como objeto de comunicação, um modelo de dados, deve ter a capacidade de
informar sobre o que representa de forma clara, sendo uma unificação do diagrama
com informações textuais, sua representação gráfica por si só normalmente não é
suficiente para gerar entendimento dos conceitos representados, entretanto um
modelo deve ser auto-explicativo, fundamental, é necessário para gerar a
interpretação correta, onde a definição do nome do objeto bem como a sua
conceituação tem o papel fundamental para gerar esse entendimento, desta forma,
nomes e definições não podem gerar ambiguidade, isto é devem ser precisa, de
forma que não gere dúvida, incerteza, interpretação de conceitos distintos.
Cada um dos elementos identificados e representados deverá ser definido
claramente para que, associando-se seu nome, sua representação e sua definição,
sejamos capazes de ter o completo entendimento do conceito que estes procuram
transmitir. Ex: Cobertura: o que serve para cobrir, para seguros.
A nomenclatura de objetos deve prever nomes breves e objetivos, que identifiquem
facilmente o conteúdo da entidade. Estar no singular, pois a pluralidade decorre,
naturalmente da cardinalidade. Ex: PESSOA, CLIENTE, CONTRATO
A definição do objeto deve ser uma definição formal dos elementos, o que irá gerar
o dicionário de dados, que devera trazer a conhecimento público a toda e qualquer
informação útil para o processo de compreensão e unificação de conceitos, que
possam parecer triviais para quem está modelando, não serão do mesmo modo
triviais para outras pessoas que não tenham conhecimento prévio.
Atributo
Atributo é tudo o que se pode relacionar como próprio da entidade (propriedade)
que de alguma maneira a qualifique e a distinga de outras, estes podem ser
classificados e identificados como:
● Atributos descritivos: atributo que seja capaz de demonstrar, ou
representar, características formadoras, ou pertencentes, a um objeto. Ex:
Data de nascimento, idade, sexo.
● Atributos Nominativos: atributo que além de cumprirem a função de
descritivos, também servem como definidores de nomes ou rótulos de
identificação aos objetos aos quais pertencem. Ex: código do..., matrícula,
número...
● Atributos Referenciais: atributo que não pertencem propriamente a
entidade onde estão, mas fazem algum tipo de referência dessa entidade com
outra entidade.
Relacionamento
Relacionamento é a relação existente entre entidades, isto é a ligação lógica entre
duas entidades que representa uma regra ou restrição de negócio, possibilitando
entender como uma entidade se comporta em relação às demais, qual o seu grau de
dependência de outras entidades e qual a associação de dados existentes entre elas.
Representação de Relacionamentos de Modelo
Podem ser estabelecidos mais de um relacionamento entre entidades, de acordo
com a regra de negócio a ser representada onde cada entidade pode participar de
vários relacionamentos.
Os relacionamentos possuem características que os tipificam.
● Cardinalidade: Indica a quantidade de ocorrências de determinado
relacionamento, Sempre a maior possibilidade, sua representação é variável
de acordo com a notação, por exemplo N para Perter Chen e Para James
Martin.
● N : várias vezes
● 1 : apenas uma vez
● 0: não acontece
● Opcionalidade: Analisa os relacionamentos pelo lado da obrigatoriedade
das ocorrências de uma entidade se ligarem às ocorrências das outras.
Podem ser de 3 tipos:
○ Opcional: quando as ocorrências das entidades que se relacionam são
independentes das outras.
○ Contingente: a obrigatoriedade só acontece por um lado do
relacionamento e somente uma entidade possui independência com
relação a outra.
○ Mandatório: As ocorrências das entidades somente podem existir se
ambas (dominante e dependente) existirem.
Existem várias bibliografias sobre as tipificações de relacionamentos, as mais
comuns são:
Representação de
Relacionamento Ternário
Representação de Relacionamento Ternário
● Ternário: um único fato que relaciona três entidades (Figura 33).
● Auto-Relacionamento: Uma entidade por relacionar com ela mesma.
● Agregação: é o relacionamento. Este relacionamento possui uma condição
de existência, que o relacionamento fundamental tem que ser
necessariamente N:N.
Representação de
RelacionamentoAgregação de Modelo de Dados.
Representação de Relacionamento
Agregação de Modelo de Dados.
● Especialização: Um grupo hierárquico de entidades que compartilham
atributos em comum.
● Entidade Supertipo: contém a chave primária e os atributos genéricos.
● Entidade Subtipo: herda a chave primária e contém os atributos específicos
de cada tipo.
https://www.devmedia.com.br/introducao-a-modelagem-de-dados/24953
Exemplo de
Relacionamento Especialização.
Exemplo de Relacionamento Especialização
Integridade
Realizada por meio de restrições, que são condições obrigatórias impostas pelo
modelo, como exemplo integridade de domínio ou referencial.
A integridade de domínio Implementa restrições nas informações armazenadas,
quanto mais limitados os dados que podem ser inseridos em um campo, menor será
a probabilidade de entrada de dados errados no banco de dados. Também
especifica quais dados são absolutamente necessários para que o banco de dados
funcione apropriadamente. Podendo ser:
● Restrições de check: Permite controlar os dados inseridos em certa coluna,
de qualquer tabela, avaliando uma expressão. Ex: maior que, menor que,
diferente de.
● Nulidade: controla se existe obrigatoriamente o valor para aquela coluna. O
valor nulo deve ser evitado, pois implica em desperdício de espaço. Deve
utilizar nulo quando o valor existe, mas é desconhecido; o valor é
conhecido, mas está ausente.
● Unicidade: Toda tabela deve ter definido um atributo ou conjunto de
atributos cujo valor ou combinação deve ser distinto em qualquer ocorrência
da tabela.
● Unique: Determina que todos os valores, de uma determinada coluna,
precisam ser exclusivos (diferentes). Gera integridade.
● Default: Estabelece um valor padrão para determinada coluna.
Atributo de uma tabela que referencia à outra tabela, a chave primária da entidade
pai que migra para a entidade filha através de um relacionamento.
A integridade referencial garante que linhas relacionadas em um par de tabelas
continuem relacionadas mesmo depois de terem sido feitas alterações na tabela,
desta forma, uma linha em uma tabela que se refere a outra tabela deve referenciar
uma linha existente naquela tabela.
Representação de Integridade entre Tabelas
Chave primária compreende a identificação única de uma ocorrência em uma
entidade, um identificador das linhas da tabela, no caso de mais de uma chave em
uma tabela, é escolhida uma chave primária, desta forma, nenhum valor de chave
primária pode ser nulo. Uma chave primária não tem nenhuma ligação com o
conceito de ordenação e com o acesso à tabela. Para questões de acesso às
informações a recomendação é a utilização de índices.
Documentação
Definição formal dos elementos (dicionário de dados), evitando assim,
ambiguidade: falta de clareza, falta de precisão, incerteza, dúvida. Cada um dos
elementos identificados e representados deverá ser definido claramente para que,
associando-se seu nome, sua representação e sua definição, sejamos capazes de ter
o completo entendimento do conceito que estes procuram transmitir. A
dicionarização deve trazer a conhecimento público toda e qualquer informação útil
para o processo de compreensão e unificação de conceitos.
Normalização
É um processo formal, passo a passo, que examina os atributos de uma entidade,
com objetivo de evitar anomalias observadas na inclusão, exclusão e alteração de
linhas específicas, tem como objetivos a preservação da integridade dos dados,
gerar estabilidade para o modelo, eliminar redundância. Dados bem definidos,
íntegros no seu significado, consistentes, confiáveis, seguros e compartilhados
fazem com que cada novo sistema defina apenas os dados que são do seu escopo e
compartilhe os demais dados com outros sistemas presentes na organização.
● Primeira Forma Normal: O objetivo é retirar os atributos ou grupos
repetitivos. Representação de informações que se repetem para a mesma
unidade, retratando ocorrências de um mesmo fato dentro de uma única
entidade, vinculado a sua chave, onde para cada chave há a ocorrência de
uma e somente uma informação de cada atributo. Desta forma, cada campo
de uma tabela precisa conter somente um único tipo de dado, e cada parcela
de dado deve ser armazenada em somente um lugar. Essa exigência é
conhecida como atomicidade de dados.
● Segunda Forma Normal: O objetivo é separar as dependências parciais. É
preciso que as tabelas estejam na primeira forma normal e que cada uma
contenha dados sobre uma e somente uma entidade, onde as colunas que
dependem parcialmente da PK, devem formar uma nova tabela, algumas
entidades, para serem identificadas e individualizadas, necessitam conter em
sua chave mais de um atributo, formando, portanto, uma chave concatenada,
verificar se a mesma possui chave concatenada e, se for o caso, constatar se
todos os tributos não chaves não apresentam dependência parcial com a
referida chave. Isto é, quando os atributos não-chaves dependem
parcialmente de chave concatenada.
● Terceira Forma Normal:: O objetivo é eliminar dependências transitivas.
Quando alguns atributos não são dependentes diretos da chave da entidade,
mas sim por transitividade, através de outros residentes na mesma entidade
referenciada. Isto é dependência indireta de um atributo com a chave da
entidade, através de outro atributo não-chave, do qual é diretamente
dependente. É preciso que as tabelas estejam na segunda forma normal e que
todos os campos não-chaves dependam diretamente da chave primária, ou
seja, não pode ter colunas determinadas por outras colunas. Os campos
calculados devem ser eliminados, desta forma é verificado se algumas
tabelas precisam ser divididas em partes, pois todas as tabelas devem conter
informações sobre somente uma coisa.
Agora Keren estou mandando um artigo de PASSO a PASSO de como construir um modelo:
A aplicação de conceitos de modelagem possibilitará uma boa performance,
facilidade de integração com outras aplicações, além da segurança que será
aumentada, já que as melhores práticas, se seguidas, enfocam questões de
segurança também.
É recomendado para o desenvolvimento de todo tipo de aplicação, independente de
sua complexidade. Também possibilitará uma documentação prática e efetiva sobre
projetos de banco de dados.
Atualmente, com a proliferação da tecnologia e as facilidades de obtenção de
novos equipamentos, assim como as novas técnicas administrativas, tem-se tornado
imprescindível que as empresas utilizem ferramentas de controle para melhorar sua
competitividade em meio à concorrência cada vez mais acirrada. Uma destas
tecnologias é o desenvolvimento e manutenção de um banco de dados que
armazene todas as informações necessárias para a tomada de decisão.
Porém, com a crescente necessidade, vem surgindo uma inundação de aplicações
pré-fabricadas que tentam suprir este mercado de consumo. Estas opções nem
sempre são capazes de atender às exigências das empresas que, normalmente, vêm
se adequando às ferramentas disponíveis. Nossa proposta é justamente
disponibilizar ferramentas que venham diretamente ao encontro das necessidades
das empresas, e para isso se torna necessário um trabalho de pesquisa e
desenvolvimento mais apurado.
Neste artigo serão apresentadas algumas das boas práticas de análise, modelagem
e distribuição de dados, integração com outras aplicações e, principalmente,
documentação de nossas tarefas, para que posteriormente fique mais simples
manter ou integrar o trabalho desenvolvido na área de banco de dados.
Iniciando uma Modelagem
Iniciar um novo projeto é uma tarefa que poderá ser bastante agradável e
compensadora se você conseguir trabalhar de forma correta, utilizando o que é
comumente chamado de “melhores práticas”, que nada mais são do que os
métodos, formas e preceitos utilizados na obtenção de melhores resultados.
Este processo será inicialmente maçante, principalmente com a grande cobrança
inicial da parte dos contratantes, pois não é um trabalho que aparecerá ao cliente,
porém, o desenrolar dos processos será perceptível tanto na questãoda
produtividade quanto na qualidade do produto final.
Também vemos esforços hercúleos de desenvolvedores, analistas e DBAs, além
das equipes de infraestrutura, para corrigir erros e adaptar a aplicação a situações
não previstas. Estes esforços se tornaram tão costumeiros que ultimamente as
equipes de manutenção são maiores do que as equipes de desenvolvimento.
Uma simples mudança na legislação, que normalmente requer urgência na
adaptação, caso contrário serão aplicadas multas à empresa, poderá desestruturar
toda a aplicação se esta não for bem projetada e planejada.
Neste artigo, nosso objetivo será direcionar o desenvolvimento de uma base de
dados que suporte não só uma grande massa de dados, como também a integração
com novas aplicações e as indispensáveis melhorias pelas quais toda aplicação
deve passar.
Também aproveitaremos para avaliar melhor o tamanho de uma base de dados de
forma a evitar que tenhamos qualquer tipo de problemas neste sentido, e como
fazer para resolver problemas quando as bases ficam significativamente grandes.
Todos estamos acostumados a consultar os tutoriais existentes na internet, porém
estes servem para solucionar problemas, poucos, quando há, são para criar
aplicações e evitar problemas.
Como nosso trabalho será voltado exclusivamente para bancos de dados, vamos
partir de um pressuposto que estamos trabalhando em conjunto com um analista de
sistemas, e vamos trabalhar na modelagem de um banco de dados para uma
aplicação simples.
Existem diversas formas de se trabalhar em modelagem de dados. Iremos aqui
demonstrar uma forma prática e simples que poderá ser muito útil aos nossos
projetos futuros. A proposta é de fazermos o trabalho em módulos, onde cada
módulo será desenvolvido separadamente e será integrado aos módulos já
existentes.
https://www.devmedia.com.br/modelagem-de-dados-tutorial/20398
Iniciando o projeto
Inicialmente vamos definir o escopo geral do projeto para que não nos percamos e
não comecemos a investir energia em ações não prioritárias. Abaixo são descritos
os passos iniciais para definirmos o escopo e também o que não será contemplado
no projeto. Contudo, faremos nossas ações sempre pensando em futuras
integrações com outros módulos e outros aplicativos.
Nenhum sistema deve funcionar isolado dos demais sistemas da empresa, nem
mesmo RH ou financeiro. Qualquer um que trabalhe desta forma é um gerador de
retrabalho, redundância de informações e, inevitavelmente, de dados incorretos e
desatualizados.
Vamos discutir os princípios básicos de um projeto de sucesso. Entenderemos
como sucesso, aquele projeto que atinge seus objetivos, cumpre seu ciclo de vida
sem trazer transtornos e tormentos a seus usuários. Indiferente de se vender
milhões de cópias ou se for para utilização interna de uma única empresa, o
sucesso estará no cumprimento dos requisitos estabelecidos para ele.
O primeiro passo é elaborar com clareza o que se deseja obter de um programa de
computador. Teremos em nossa primeira etapa a definição clara do que desejamos
fazer, primeiro uma definição macro e vamos tornando-a cada vez mais detalhada
até que possamos descrever cada módulo com total clareza.
Desenvolvendo em módulos
É interessante se trabalhar com o desenvolvimento de aplicações por módulos
principalmente porque você pode disponibilizar ao cliente/usuário final as partes
do programa que serão utilizadas enquanto outro módulo está em desenvolvimento.
Presenciei muitos projetos que foram encerrados por que quando estavam
próximos à sua conclusão, não tinham mais serventia, pois tentou-se fazer o
projeto por inteiro, ou então a verba foi cortada.
Outra boa argumentação sobre esta forma de trabalho é que, havendo a necessidade
de se trabalhar uma manutenção ou melhoria, apenas um módulo, isto é, uma parte
do todo, será revisto, pois ele será o responsável por aquela informação. Os demais
módulos, por estarem integrados com aquele que foi modificado, receberão as
informações corretas, sem que seja necessário sofrer qualquer manutenção extra.
E o principal motivo que justifica este tipo de desenvolvimento é que você não
precisará ficar procurando em milhares de linhas de programação os pontos que
apresentam algum tipo de problema.
Quem trabalhou no famoso BUG do ano 2000 saberá do que estou falando.
Pesquisamos milhões de linhas de programação, procurando por alguma parte do
sistema que não estava utilizando os quatro dígitos do ano para modificá-lo. Isso
também inclui centenas e até milhares de tabelas, dependendo do porte da empresa.
Se os processos e a modelagem (que não existia na maioria das empresas) fossem
modulares, seria muito mais simples este tipo de manutenção.
Existem empresas cuja programação não só não é modular, como também
extremamente sem considerar qualquer tipo de padrão de desenvolvimento
(particular até mesmo para clientes diferentes de uma mesma aplicação). Quando
encontravam algum erro, tinham que procurar em todos os servidores de aplicações
para identificar quais os programas que continham aquele tratamento de
informação. Invariavelmente, algum programa específico passava despercebido,
gerando incoerências e divergências contábeis bastante significativas, o que
poderia gerar inclusive processos judiciais.
Saiba mais
Série Eu sobrevivo sem UML?
No contexto deste artigo, utilizaremos uma aplicação de fácil entendimento e
visualização para facilitar o entendimento do problema.
https://www.devmedia.com.br/uml/
https://www.devmedia.com.br/uml/
Modularidade
Podemos desenvolver, para iniciar, a modelagem de uma aplicação que controle
uma mercearia ou um mercado. Estipularemos o que desejamos controlar e depois
vamos definir como modularizar a aplicação.
Com já foi dito, não é conveniente tentar desenvolver módulos de forma
simultânea, a menos que se trate de uma fábrica de software muito bem integrada e
utilizando métodos sofisticados de desenvolvimento, como o SCRUM. Assim,
trataremos os módulos de forma individual e contínua. Também gostaríamos de
ressaltar que não estamos tratando com programação, estamos trabalhando na
modelagem de um banco de dados para abrigar uma aplicação.
Nota: Scrum é uma forma das equipes trabalharem juntas para desenvolver um produto. Este
desenvolvimento ocorre em pequenos pedaços, com cada peça construído sobre peças criadas
anteriormente. Este método de desenvolvimento estimula a criatividade e permite que as
equipes possam responder ao feedback dos clientes e trabalhar nas mudanças para construir
exatamente e apenas o que é necessário.
Definindo o escopo
Se vamos controlar uma mercearia ou mercado, temos que definir onde começa e
onde termina nosso projeto, inclusive as partes que simplesmente não fazem parte
https://www.devmedia.com.br/guia/scrum/34636
https://www.devmedia.com.br/cursos/banco-de-dados
de nosso escopo e as partes que poderão fazer parte do escopo em uma segunda
fase.
Folha de pagamento, controle de ponto, faltas, benefícios e outras atribuições
ligadas a departamento de recursos humanos, apesar de serem importantes, não
fazem parte do controle da mercearia, portanto vamos deixar de fora de nosso
escopo inicial.
Contas a pagar e receber, assim como fluxo de caixa, mesmo fazendo parte de
nosso escopo geral serão deixados para uma segunda etapa, já que para se obter as
informações que alimentarão estes módulos necessitaremos de outros módulos aos
quais daremos prioridade. Portanto, iremos nos concentrar no que o cliente tem de
maior urgência, isto é, controlar seu empreendimento.
Para isso, podemos realizar uma sessão de brainstorm sobre a aplicação. Esta é
uma atividade que muitas empresas deveriam utilizar, mas sem o preconceito e sem
predeterminações, pois ir a uma reunião onde serão feitas muitas sugestões e
encontrar restrições aos seus pensamentos é como enterrar este tipo de iniciativa.
Nota: Tempestade mental, uma alusão à tempestade de ideias, dirigidas por todos os
membros de uma equipe a respeito de um determinado assunto. Depois de tudo anotado,
escolhe-seo que é importante, o que é relevante, o que pode ser aproveitado e o que deve ser
descartado.
Esta aplicação deve inicialmente controlar o estoque. Para isso deve ter um cadastro completo
de produtos. Para se ter um cadastro de produtos, necessitaremos de um cadastro de
fornecedores. Teremos também que possuir uma entrada de mercadoria que possibilitará o
controle de estoque assim como a validade dos produtos. A partir destas informações,
teremos a possibilidade de controlar também as contas que teremos a pagar (mesmo não
fazendo parte do escopo inicial, estas informações deverão ser contempladas ou ,pelo menos,
previstas).
Um dos grandes erros na modelagem está em definir a obrigatoriedade de todas as
informações que poderão ser utilizadas no futuro, tornando o simples cadastro de um item um
verdadeiro transtorno para seus clientes. É interessante também, dependendo do contratante,
ter um cadastro de clientes, o que possibilitará uma maior integração e conhecimento dos
clientes. Isto permitirá também que o sistema possa acompanhar seus hábitos de consumo,
frequência, sugestões de produtos e serviços, enviar mala direta, etc.
Tamanho dos dados
Com base neste escopo macro que foi elaborado, pode-se pensar, por maior que
seja a mercearia ou o mercado, quantos produtos distintos serão armazenados no
banco? Quantos fornecedores? Fluxo de entrada de mercadorias, vendas? Esta é
uma atividade normalmente entregue a um profissional chamado Administrador de
Dados (AD), pois ele irá quantificar estas informações, definir o tamanho de uma
base de dados para o primeiro ano e depois, seu crescimento para os próximos
cinco anos.
Neste caso, estamos trabalhando com uma massa de dados bastante restrita, onde
um banco de dados “parrudo” não se tornará necessário. Existem diversos bancos
de dados de utilização livre, que poderão comportar esta aplicação com bastante
segurança e versatilidade.
Pode-se sugerir o MySQL, PostgreSQL ou FireBird, que são bancos bastante
simples de se instalar, implementar e dar manutenção. Bancos de dados mais
corporativos como SQL Server, Oracle, DB2 entre outros, são normalmente mais
interessantes de serem utilizados em aplicações que possuam massa de dados
grandes e complexas o suficiente para justificar estas plataformas.
Não é anormal nem errado possuir diversas plataformas de bancos de dados em
uma empresa. É verdade que a diversidade torna a administração um tanto quanto
mais complexa, porém é comum vermos diversos tipos de aplicação com seus
respectivos bancos de dados. O ideal deste processo é possibilitar a integração
entre as aplicações, evitando redundância e discrepância entre as informações.
As tabelas, no padrão SQL, possuem um comportamento um tanto quanto
previsível, portanto, podemos fazer uma primeira modelagem e, a partir dela,
fazermos o trabalho de AD na escolha de um banco de dados mais apropriado.
Levantamento de informações
O primeiro passo que devemos trabalhar é a questão de módulos. Temos que
quebrar nossos grupos de informação de forma a ser possível um controle mais
efetivo sobre cada etapa do desenvolvimento.
Quando pensamos em fazer uma modelagem de dados, a primeira questão que nos
vem à mente é começar a criar as tabelas e fazer seu relacionamento. Entretanto,
existem outras etapas que devem ser concretizadas antes de irmos para a
ferramenta de modelagem.
A primeira forma normal, de modelagem de dados, nos indica que devemos fazer
uma relação simples e direta de tudo o que envolverá a parte da aplicação que será
modelada. Como nosso cliente tem pressa de colocar a mão na massa,
principalmente ele quer ter certeza de que alguma coisa está sendo feita, então
vamos projetar os dados referentes ao cadastro de produtos. Assim, enquanto ele
está cadastrando seus produtos nós desenvolveremos outra parte da aplicação.
Vamos pensar no que envolve o cadastro de produtos. Um bom ponto de partida é
conhecer o ambiente sobre o qual será desenvolvido o projeto, portanto, nada
melhor do que passear pelo estoque do cliente e por outras empresas semelhantes e
ver seus produtos, levar uma caderneta e anotar todas as informações que possam
ser úteis ao seu cadastro.
Cuidado sempre para anotar informações completas, anote tudo, desde o nome do
produto, validade, quem embala e produz, quais os valores calóricos, tipo de
embalagem, peso, vá anotando tudo o que encontrar de importante e até mesmo
irrelevante. Depois faremos outro brainstorm para ver o que entrará em nossa
modelagem, o que é importante e o que pode ser útil, mas dispensável.
Só poderemos selecionar o que precisamos se tivermos informações o suficiente,
portanto, não existe neste momento informação inútil. Passe por diversos tipos de
produto, enlatados, conservas, laticínios, massas, etc. Lembre-se, esta é uma fase
inicial de levantamento de informações, nem tudo o que será anotado será usado,
mas deixe a decisão do que será dispensado para quando for avaliar suas
anotações.
Após ter passado pelos diversos setores, feito todas as suas anotações, você
perceberá que possui uma gama muito grande de dados, muito mais do que
imaginava inicialmente. Esta é uma das grandes surpresas de quem experimenta a
modelagem de dados desde seu início.
Normalização
Normalização é a atividade que estabelece, em relação a problemas existentes ou
potenciais, prescrições destinadas à utilização comum e repetitiva com vistas à
obtenção do grau ótimo de ordem em um dado contexto. Na prática, ela está
presente na fabricação dos produtos, na transferência de tecnologia, na melhoria da
qualidade de vida através de normas relativas à saúde, à segurança e à preservação
do meio ambiente.
Também podemos entender, dentro dos conceitos de bancos de dados, que
normalização é a decomposição das informações levantadas de forma que não haja
redundância, evitando assim possíveis problemas de atualização. Este processo
deve manter a integridade das informações ali contidas, mantendo-se a semântica e
as restrições pertinentes.
Quando queremos armazenar o conteúdo de nome do produto em uma tabela, não
faz sentido algum chamar esta coluna de informações de A1, por que não nos trará
nenhuma informação clara de seu conteúdo. Serão necessárias várias incursões a
códigos-fonte das aplicações para conhecer o seu conteúdo.
Existem aplicações que necessitam ser totalmente reescritas por causa da falta de
documentação e da inviabilidade de se obter informações concretas sobre os dados
ali armazenados, muita informação foi perdida.
Portanto, ao definir colunas de informações, seja claro ao documentar, tanto as
tabelas quanto as informações ali contidas. Algumas “coisas” devem ficar fora de
nossa modelagem, tabelas auxiliares e temporárias. Estas poderão ser necessárias
para alguma extração e em algum momento para auxiliar ETL (processo de
extração, transformação e carga de dados) ou a programação, mas não farão parte
de nossa documentação inicial.
Primeira etapa
Primeiramente, você deve saber o que o seu cliente deseja controlar e como ele
deseja controlar estas informações. Não devemos desenvolver um sistema muito
complexo e também não será útil projetar um sistema simples demais tornando-o
incompleto.
Caso você possua uma lousa ou um flip chart, utilize-os, pois é muito mais simples
visualizar as informações em uma destas “ferramentas de apoio”. Depois de
colocar todas as informações colhidas em um local grande e facilmente visível,
vamos começar a separar as informações por tipo de dado e por aproximação.
Vamos trabalhar com alguns exemplos de informações para se ter uma ideia do que
é tipo de dado e o que é aproximação.
Vamos pegar para iniciar nosso trabalho, grãos, por exemplo, feijão, arroz, lentilha.
Como estes produtos são comercializados? Podem estar ensacados, enlatados, em
pacotes, caixas ou a granel. Como nosso cliente gostaria que estes produtos fossem
controlados? Por tipo de produto? Por unidade de armazenamento? Por variedade?
Estas questões são importantes para que possamos definir como projetaremosnosso banco de dados.
Caso nosso cliente queira controlar por tipo de produto, por exemplo, feijão, então
teríamos que ter um produto cadastrado e uma tabela auxiliar contendo as
possibilidades de armazenamento: saco, lata, granel, etc.
Se ele desejar um controle mais genérico, então no cadastro já constará todas as
informações relacionadas ao produto. O importante é que a visualização dos
cadastros seja totalmente amigável, o cliente não precisa saber em que níveis de
detalhe está entrando, tampouco de que forma estas informações estão
armazenadas.
O mais importante é que a documentação desta modelagem seja suficientemente
clara para futuras manutenções e implementações.
Então vamos fazer uma documentação completa, evitando assim futuros
esquecimentos e facilitando manutenções e eventuais atualizações. Assim, nesta
primeira etapa levantamos todas as informações que podem ser úteis ao cliente.
Segunda etapa
Não iremos nos ater à nomenclatura. Vamos deixar os nomes das informações
como foram levantadas inicialmente. O que importa é que não haja redundância e
também não existam falhas em partes do levantamento. É muito comum que o
levantamento inicial não leve em considerações exceções e deixe de considerar
pontos aparentemente insipientes, por isso que coloquei que deveremos andar por
toda a loja, verificando os mais diversos tipos de mercadoria e as mais variadas
informações.
Assumiremos que o dono do estabelecimento não queira dados mais rebuscados,
então vamos fazer uma modelagem mais simples para definirmos nossa
modelagem de produtos.
Todo produto deve ter um nome, isso é bastante evidente. Também necessitará de
um código de identificação. Aqui teremos nossa primeira decisão importante a
tomar tendo-se em vista que nem todo produto possui um código de barras.
Torna-se necessário ou a utilização de uma impressora de código de barras para os
produtos que não possuem ou então a utilização de um código sequencial para
todos os produtos.
Todo produto tem um ou mais fornecedores. Em alguns casos, como produtos a
granel, podemos ter mais de um fornecedor para o mesmo produto, então não
poderemos ter o fornecedor diretamente ligado ao produto, sendo necessária uma
tabela intermediária.
Usando esta mesma sequência de raciocínio, devemos separar as informações em
grupos que posteriormente serão convertidos em tabelas. As informações devem
estar agrupadas de acordo com sua similaridade e/ou proximidade, não deve haver
redundâncias, pelo menos neste primeiro momento.
Existe uma teoria que defende a desnormalização de dados, porém este tipo de
trabalho é algo que exige um bom conhecimento em modelagem de dados e uma
larga experiência em aplicações. Este é um caminho perigoso, já que haverá
redundâncias e subutilização de tabelas, além de uma sobrecarga na massa de
dados e um trabalho considerável em sua manutenção constante.
Quando formos trabalhar com código de barras, é interessante verificar quais são
as normas vigentes no momento. É sempre saudável que validemos as informações
que usaremos para desenvolver os projetos. Isso evitará problemas futuros,
lembrando sempre de documentar as fontes de informação utilizadas para a tomada
de decisão. Isto poderá parecer um tanto quanto burocrático, mas é a melhor forma
de se prevenir contra futuros descompassos.
Lembre-se sempre de consultar sites oficiais, isso obviamente excluirá todo e
qualquer blog, Wikipédia, e outros sites não oficiais. Se um destes for realmente
sério, fornecerá a fonte e você deve ir à fonte para conhecer o conceito completo.
Quando fazemos esta primeira separação de informações, estamos realizando a
segunda etapa da modelagem. Neste momento ainda não se mostra necessária a
definição de nomes e tamanho de dados, também não precisamos nos preocupar
com as chaves primárias (PK) e estrangeiras (FK), vamos nos ater apenas às
informações que deverão ser agrupadas. Porém, até aqui já tomamos todas as
precauções necessárias para que não haja redundância de informações,
duplicidades, incompatibilidades, etc.
Terceira etapa
Agora partiremos para a terceira etapa da modelagem. É aqui que começaremos a
dar nomes e tamanhos às informações que serão armazenadas. Existem diversas
formas de se nomear as tabelas e colunas, porém, acredito quanto mais simples e
direta for a informação, mais fácil será identificar seu conteúdo e trabalhar em
manutenções e integrações.
O primeiro passo é encontrar o núcleo da informação, neste caso, como estamos
trabalhando em um cadastro de produtos, torna-se evidente que todas as
informações orbitarão em torno desta tabela principal.
Então, na tabela de produtos, teremos o código e nome do produto, devemos
classificar qual o tipo de envasamento deste produto, isto é, se é enlatado,
ensacado, engarrafado, por peso, etc., qual o peso ou quantidade. Devemos
considerar também as informações valor de compra e de venda.
Teremos como tabelas de apoio: unidade de medida e tipo de embalagem. Você
pode questionar por que este tipo de tabela, a justificativa é simples, quanto menos
oportunidades as pessoas tiverem de errar no cadastro, melhor.
Exemplificando, se em um produto a pessoa cadastra LITRO, em outro ela cadastra
Litro, ou litor(com erro de digitação), então, caso exista a necessidade de alguma
correção, será bem mais simples fazê-la em único lugar, que se refletirá em todos
os produtos.
Também colocaremos a possibilidade de pacotes, isto é, “combos” que possuem
vários de um mesmo produto, ou combinados. Isso também poderá ser considerado
em seu levantamento.
Colocando em prática
Agora está na hora de colocar em prática esta parte do trabalho que foi discutida.
Como foi definido que a tabela de produtos será a base deste módulo, então iremos
nos concentrar nela e projetar também as tabelas auxiliares conforme tenhamos a
necessidade.
Todo produto deverá ser identificado por um código único, como definimos a
utilização de um código de barras, então usaremos uma coluna alfa numérica.
Assim como um código, este produto precisa de um nome. Não confunda nome
com descrição, por exemplo, Ovomaltine é nome, achocolatado é descrição, já que
tanto Nescau quanto Toddy são achocolatados. Em sua modelagem você pode ter
um campo descrição (isso vai depender dos objetivos de seu cliente).
Da mesma forma, todo produto vem embalado, com exceção dos produtos a granel.
No caso do Ovomaltine, o encontraremos em sacos econômicos e em potes
plásticos, além, é claro, de quantidades distintas. Para evitarmos que a cada
produto seja dada uma descrição diferente para o tipo de envasamento, então é
aconselhável que tenhamos uma tabela auxiliar. Neste caso, tipo de envase, que
terá basicamente o código identificador e a descrição.
Todo produto deve ter uma unidade de medida (metros, quilos, litros, etc.) também
para evitarmos que sejam feitos cadastramentos distintos. Iremos criar uma tabela
de apoio que terá o código identificador da unidade de medida, sua descrição por
extenso e sua descrição curta, por exemplo, metro como descrição e m como
descrição curta.
É aconselhável que o valor unitário de compra faça parte deste cadastro. Esta
informação deve ser recalculada a cada nova entrada já que fornecedores distintos
trabalham com valores distintos. Em país que há inflação, os valores devem estar
sempre sendo recalculados. Com base neste valor, é possível perceber se o valor de
venda ainda está dentro da lucratividade estabelecida ou se está na hora de
remarcar preços.
Outra informação indispensável é a quantidade em estoque, tanto para produtos de
alta rotatividade quanto para produtos de baixa rotatividade, pois saber a hora de
recompor o estoque é imprescindível (uma loja com prateleiras vazias terá sérios
problemas de caixa em pouco tempo).
Vimos até aqui que, ao definir a tabela de produtos, também definimos
indiretamente outras duas tabelas que nos auxiliarão na identificação dos mesmos.
Outra tabela importante é a de pacotes ou kits, isto é, quando existem diversos
itens do mesmo produto, por exemplo,pacotes de papel higiênico, ou itens de
produtos distintos, como shampoo e condicionador, compondo um kit. Este deve
ser catalogado não como um produto diferente e sim como uma promoção. Neste
caso, teremos um novo preço de produto, que é a composição dos valores de
compra de todos os itens que pertencem ao pacote, e teremos um valor de venda.
Novamente podemos ou não ter uma coluna controlando a quantidade de pacotes,
porém muitos mercados criam pacotes simbólicos, isto é, se você comprar
determinados produtos, formando um pacote, a soma destes será menor que a
compra individual destes mesmos produtos. A inclusão de uma coluna de
quantidade em estoque vai depender exclusivamente de seu cliente.
Para que possamos desfrutar da melhor forma possível este conceito de pacotes,
então criaremos mais uma tabela auxiliar, que fará a ligação entre pacotes e
produtos. Observe como ficou nosso projeto de banco de dados na Figura 1.
Figura 1. Estrutura simplificada do primeiro módulo a ser desenvolvido
Para alimentar estas tabelas, devemos iniciar pelas tabelas auxiliares, neste caso,
Unidade de Medida e Tipo de Envase, pois sem estas informações não será
possível cadastrar os produtos que dependem destas informações para compor seu
cadastro.
Para cadastrar os itens do pacote, deve-se primeiro criar o registro em pacote,
depois alimentar a tabela Produto x Pacote, caso contrário ficará inviável seu
cadastramento.
Análise
Ao examinarmos como ficou nossa primeira modelagem, na Figura 1, notamos
que os nomes das tabelas aparecem de forma simples, facilitando sua identificação.
É uma boa prática sempre utilizar o singular.
Da mesma forma, temos que ter um padrão para nomear as colunas de informação,
de id identificação, cod quando vamos trabalhar com códigos alfanuméricos, num
quando vamos trabalhar com informações numéricas, assim por diante.
Uma vez que se definiu que cod_produto será o código do produto, esta
nomenclatura deverá ser utilizada em todo o resto da aplicação. Devemos evitar
que colunas do tipo cod_cliente, cod_cli, cliente, num_cliente, surjam em
nossas aplicações.
Devemos evitar também que colunas com tipos de dados e/ou tamanhos diferentes,
venham compor nossas aplicações, pois construir uma integração nestes casos
torna-se um trabalho incrivelmente complexo. Caso isso ocorra, teremos que
aplicar conceitos de refatoração para ajustar o banco de dados. A refatoração, neste
caso, pode ser entendida como sendo um processo de “higienização” do banco de
dados e dos processos envolvidos em toda a aplicação, é um processo minucioso e
detalhado de pequenas alterações efetuadas de forma constante e renovadora em
todo processo.
Conclusão
Com o que foi apresentado neste artigo, poderemos explorar todas as
possibilidades de levantamento nos mais diversos tipos de aplicação, desde que
sigamos sempre as melhores práticas.
Aproveite para pesquisar um novo assunto, por exemplo, bibliotecas, locadoras,
etc., pois são áreas que, mesmo havendo uma grande oferta de produtos prontos, há
uma grande carência de aplicações desenvolvidas de acordo com as necessidades
dos clientes.
Por fim, vale destacar que devemos estar sempre atentos também à praticidade das
informações cadastradas. Se fizermos uma modelagem excessivamente rebuscada,
o desenvolvimento das aplicações que irão alimentá-la será complexo e
provavelmente confuso, portanto a simplicidade é a “ordem do dia”.
Desde já peço desculpas se não correspondi ao que você esperava, estamos aqui
para tirar e talvez ponderar sobre algumas reclamações.