Artigos Banco de Dados Modele um banco de dados em MySQL

De que se trata o artigo

O artigo aborda a modelagem de um sistema que gerencia um campeonato de futebol. Neste artigo, é feita a modelagem de triggers e stored procedures para atualização constante e consultas ao banco de dados de cada campeonato, gerando a classificação dos times e estatísticas sobre o campeonato.


Para que serve

Serve como estudo de caso para os profissionais interessados em exemplos de modelagem de banco de dados utilizando triggers e stored procedures.


Em que situação o tema é útil

O desenvolvimento de sistemas computacionais envolve a codificação da aplicação e construção do seu banco de dados. Este artigo descreve a modelagem de um banco de dados para um estudo de caso, sendo útil para profissionais (DBAs) que precisam modelar e construir bancos de dados para sistemas de informação.

Resumo Devman

A modelagem de dados em sistemas de informação é sempre uma atividade importante a fim de viabilizar o armazenamento e acesso às informações que um sistema lida. Uma má modelagem dos dados irá impactar diretamente na qualidade do sistema a ser construído ou mantido.

O primeiro passo para criação do banco de dados será a definição de suas tabelas e campos, bem como sua normalização para um melhor desempenho. O objetivo da normalização de dados é evitar problemas que possam provocar falhas, assim minimizando redundâncias e inconsistências. Isso possibilita uma maior facilidade na manipulação do banco de dados e na manutenção dos sistemas de informação.

Modelagem de software é a atividade de construir modelos que expliquem as características ou o comportamento de um software ou de um sistema de software. Na construção do software os modelos podem ser usados na identificação das características e funcionalidades que o software deverá prover (análise de requisitos), e no planejamento de sua construção.

Frequentemente a modelagem de software usa algum tipo de notação gráfica e são apoiados pelo uso de Ferramentas CASE. A modelagem de software normalmente implica na construção de modelos gráficos que simbolizam os artefatos dos componentes de software utilizados e os seus inter-relacionamentos. Uma forma comum de modelagem de programas procedurais (não orientados a objeto) é através de fluxogramas, enquanto que a modelagem de programas orientados a objeto normalmente faz uso da UML.

Sendo um pouco mais específico, a modelagem de dados é a atividade de especificação das estruturas de dados e regras de negócio necessárias para suportar uma área de negócios. Representa um conjunto de requisitos de informações de negócio. É uma parte importante do projeto de um sistema de informação.

A abordagem normalmente utilizada para lidar com o assunto atende a três perspectivas: Modelagem Conceitual, Modelagem Lógica e Modelagem Física. A primeira é usada como representação de alto nível e considera exclusivamente o ponto de vista do usuário criador do dado, a segunda já agrega alguns detalhes de implementação e a terceira demonstra como os dados são fisicamente armazenados.

No processo de desenvolvimento de qualquer sistema, a regra de negócio visa detalhar as funcionalidades particulares do software. Com isso, facilita por parte dos programadores o desenvolvimento de métodos de tratamento de exceções, particularidades que o sistema possa executar e o mais importante, limitar ações fora do processo normal de funcionamento de um sistema específico.

Neste artigo, daremos continuidade ao banco de dados que atenderá um sistema de gerenciamento de um campeonato de futebol, onde abordaremos de forma prática a implementação de Stored Procedures e Triggers, assim automatizando algumas das regras do negócio diretamente em nosso banco de dados.

Relembrando o sistema

O sistema que estamos desenvolvendo trata do gerenciamento de campeonatos de futebol amador ou profissional. Como estamos já em ritmo da Copa de 2014, que será no Brasil, iremos trabalhar com este domínio a fim de entender alguns conceitos relcionados à modelagem, criação e gerenciamento do bancos de dados.

A Figura 1 nos mostra a estrutura de nosso banco de dados através de seu modelo físico, facilitando o entendimento para as implementações que serão efetuadas no banco. Ao total, temos seis tabelas em nosso banco de dados:

• Campeonatos: armazena informações sobre os campeonatos, seja ele amador ou profissional.

• Clubes: armazena informações sobre os clubes que podem participar de campeonatos.

• Clubes_Campeonatos: representa o relacionamento entre as tabelas Campeonatos e Clubes.

• Jogadores: armazena informações sobre os jogadores que atuam nos clubes.

• Jogos: armazena informações sobre os jogos realizados ao longo de um campeonato.

• Jogadores_Jogos: representa o relacionamento entre as tabelas Jogadores e Jogos.

Figura 1. Modelo físico de dados

Entendendo as regras de negócio

Com as tabelas já criadas, passaremos então ao entendimento das regras de negócio afim de definir como será o funcionamento do banco de dados, ou seja, seu comportamento, suas restrições e validações.

Temos que nos assegurar que o sistema trará informações confiáveis dos clubes e sobre suas participações em jogos, os seus resultados, informações dos seus campeonatos e também armazenará informações dos jogadores referentes a cada clube. Para possibilitar de forma consistente a realização de todas estas operações, iremos implementar Stored Procedures e Triggers que controlarão as seguintes informações:

• O cadastro dos jogos, de forma que a tabela Clubes_Campeonatos seja atualizada automaticamente. Assim que um jogo for cadastrado, juntamente com seu resultado, será somado 03 (três) pontos ao clube vencedor e 0 (zero) ao perdedor. Caso ocorra empate, será somado 01 (um) ponto para cada clube;

...
Quer ler esse conteúdo completo? Tenha acesso completo