Este artigo descreve conceitos fundamentais sobre modelagem de dados e as melhores práticas para o desenvolvimento de uma aplicação. Para isso, são abordadas as questões sobre o que deve ou não ser levado em consideração ao se modelar uma nova aplicação, pontos que devem ser questionados e o que deve ser pesquisado antes de iniciar-se uma nova aplicação. Por fim, teremos a modelagem da primeira etapa de nossa aplicação, que poderá ser integrada tanto às próximas etapas quanto a aplicações existentes.
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ão da 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.
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.
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.
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 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.
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 projetaremos nosso 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.
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”.
Saiu na DevMedia!
- Primeiros passos no Flutter:
O Flutter é um framework construído pelo Google para facilitar o desenvolvimento multiplataforma. Nessa série veremos como iniciar nessa tecnologia que permite a criação de aplicativos tanto para Android quanto para iOS.
Saiba mais sobre Modelagem ;)
- Modelagem de Dados:
Essa guia terá como objetivo apresentar a modelagem de dados, desde seus primeiros passos com banco pequenos até a modelagem para bancos Big Data.
