Nós, seres humanos, possuímos um limite da quantidade de informações que podemos tratar de uma única vez. Quando estamos diante de um problema, para o qual temos que apresentar solução, procuramos identificar o que é relevante e o que pode ser descartado, de modo que possamos concentrar esforços na busca do meio mais adequado para solucioná-lo. A isso chamamos de abstração.
A técnica de abstração é utilizada por diversas áreas da computação, pois permite reduzir a complexidade de problemas, de modo que as soluções possam ser mais facilmente identificadas, descritas e gerenciadas.
A essência da ciência da computação é a identificação dos problemas contidos nos diversos segmentos da atividade humana, com o objetivo de apresentar uma solução computacional. Dividir o processo de solução desse problema em fases é uma tentativa de redução de sua complexidade. Existem atualmente diversas propostas disponíveis que determinam como os softwares devem ser criados e mantidos. Embora existam diferenças, podemos encontrar três fases clássicas que, de uma maneira ou de outra, sempre aparecem nas abordagens. As fases são: análise, projeto e implementação.
Na fase da análise, o objetivo é identificar e modelar os conceitos envolvidos no domínio do problema e de que forma esses conceitos se relacionam. Utilizando a técnica da abstração, o produto gerado nessa fase não deverá fazer qualquer referência, por exemplo, à linguagem de programação que utilizaremos para implementar o software, pois neste momento essa informação não é importante.
Quando iniciamos a fase de projeto, aspectos como ambiente de desenvolvimento, arquitetura do software e tecnologia que utilizaremos passam a fazer parte do processo de tomada de decisão. As informações identificadas nessa fase estão contidas no domínio da solução; ao contrário, as informações identificadas na fase da análise fazem parte do domínio do problema. A fase de implementação consiste na transformação do projeto de baixo nível –produto gerado na fase de projeto – para uma linguagem de programação previamente selecionada.
Uma abordagem, nas fases iniciais do processo do software, voltada para questões que dizem respeito à tecnologia dificulta a visualização da solução mais adequada para o problema do cliente. Deve-se ter em mente que o cliente está interessado na solução para o seu negócio, independente de qual ambiente tecnológico aquela solução será implementada.
Sabemos que, em determinadas situações, a tecnologia já está definida mesmo antes de iniciar o projeto do software. Mesmo nesses casos, é importante desenvolver uma solução independente de tecnologia, de modo que possa ser reutilizada em projetos futuros. Quando iniciamos um processo de desenvolvimento de software a única certeza que temos é que o software irá mudar. Além disso, a velocidade de ascensão e queda das tecnologias no mundo da informática não encontra precedentes na história. Portanto, atrelar suas regras de negócio a uma solução tecnológica pode trazer transtornos no futuro.
O projeto de banco de dados é uma atividade que tem como objetivo identificar, modelar e implementar um modelo de dados consistente com as necessidades dos usuários, que foram expressas na especificação de requisitos. Neste momento, as preocupações da equipe estarão voltadas para questões que dizem respeito à persistência dos dados. Ao longo desse artigo e de outros em edições futuras, serão descritos os passos de um projeto de banco de dados.
Realizar um projeto de banco de dados é importante porque: i) permite disponibilizar as informações de forma estruturada e eficiente; ii) evita a duplicação de informações e aumenta a confiabilidade dos sistemas; iii) define um planejamento que deverá ser seguido pelos membros da equipe; iv) possibilita a definição dos prazos, bem como os mecanismos de acompanhamento; v) possibilita a identificação e alocação dos recursos necessários e disponíveis; vi) possibilita a reutilização dos artefatos produzidos em outros projetos, entre outros.
Outra vantagem de um projeto de dados bem delineado e realizado é a documentação gerada, que servirá de meio de comunicação entre os membros da equipe. A ausência de documentação em geral é identificada como um dos maiores obstáculos para a manutenção dos produtos de software.
Ao iniciar o projeto de um banco de dados, normalmente somos forçados a pensar em como o banco será implementado. Quantas tabelas haverá, quantos campos, o tamanho e tipo de cada um, se existirá Stored Procedures, Views e principalmente qual o SGBD (Sistema Gerenciador de Banco de Dados) será utilizado.
Claro que são questões importantes para o sucesso do projeto, pois terão impacto na funcionalidade e até mesmo na performance do banco de dados; entretanto, nas fases iniciais do processo essas questões são irrelevantes. Os administradores de banco de dados devem sempre focar as regras de negócio do cliente quando se inicia um projeto de banco de dados, deixando a parte física para as fases mais adiantadas do processo.
Da mesma forma e pelos mesmos motivos que o projeto do software, o projeto do banco de dados é dividido em três grandes fases. A primeira é o Modelo Lógico, a segunda é o Modelo Físico e a terceira é a implementação. Agora vamos entender o que é o modelo lógico.
Nota: As fases de um projeto de banco de dados recebem nomes diferentes, de acordo com a literatura. O Modelo Lógico pode ser encontrado na literatura com a denominação de Modelo Conceitual; e o Modelo Físico, pode ser denominado de Projeto Lógico. A denominação da fase de implementação do banco de dados é utilizada de modo uniforme.
Modelo Lógico
Esta é a fase que modela a análise dos requisitos, onde o cliente indicou qual é o problema e o que ele espera obter com a solução. De posse das informações passadas pelo cliente, podemos iniciar a modelagem lógica do nosso banco de dados. Abaixo segue a análise dos requisitos realizada com o cliente.
Análise dos Requisitos
No exemplo que faremos durante todo o artigo, o nosso cliente será uma livraria que possui as seguintes informações e regras de negócio:
- A livraria Book.Net é destinada a clientes da área de informática. Ela possui cerca de 4.500 livros sobre desenvolvimento, internet, banco de dados, redes, sistemas operacionais, entre outros;
- A livraria tanto vende seus livros como também os aluga para clientes cadastrados em suas fichas, para fins de estudos;
- Os livros podem ser nacionais ou importados;
- Os clientes só podem alugar no máximo três livros de uma só vez, cuja duração não poderá ultrapassar o período de duas semanas. Depois desse tempo, o cliente pode renovar o aluguel. Em toda renovação, deverá ser paga uma taxa para cada livro. Caso o cliente passe do tempo e não renove o aluguel, pagará uma multa na devolução e/ou na renovação;
- Os clientes que desejam alugar um livro que já esteja alugado poderão fazer uma reserva do mesmo para aluguel posterior;
- Os livros que são pouco alugados ou não são alugados, a livraria realiza promoções para vendê-los;
- Os clientes que mais alugaram e mais compraram livros são notificados antes dos outros clientes sobre as promoções dos livros tanto para compra como para aluguel;
- Os clientes podem ser pessoas físicas ou jurídicas. Os livros também são vendidos para universidades, centros educacionais e quaisquer cursos que desejam melhorar sua biblioteca;
- O cliente pessoa física, ao se cadastrar, deve informar os seguintes dados obrigatórios: nome completo, identidade e/ou CPF, data de nascimento, endereço completo e pelo menos um telefone de contato. As informações opcionais são: e-mail, home-page pessoal e outros tipos de telefones;
- O cliente pessoa jurídica, ao se cadastrar, deve informar os seguintes dados obrigatórios: CNPJ, razão social, endereço completo e pelo menos um telefone de contato. As informações opcionais são: e-mail, home-page e outros telefones;
- Ao cadastrar um livro, as seguintes informações são preenchidas: ISBN, nome do livro, nome da editora do livro, autor do livro, ano de publicação, assunto, se é para compra ou aluguel, se é nacional ou importado e quantidade que a livraria tem. Estas são informações obrigatórias. As informações opcionais são: preço de venda, preço de aluguel e preço de renovação de aluguel.
Com base nos requisitos descritos anteriormente, o cliente deseja que o sistema forneça as seguintes funcionalidades:
- Controlar o cadastro de todos os clientes que compram e alugam os livros;
- Controlar o cadastro de todos os livros;
- Controlar os livros mais vendidos e alugados;
- Controlar os livros menos vendidos e alugados;
- Controlar as reservas dos livros;
- Controlar os livros que estão alugados e o tempo de aluguel dos mesmos;
- Obter relatório da quantidade de livros de um determinado assunto;
- Obter relatório da quantidade de livros de uma determinada editora.
De posse das informações acima, o próximo passo é a identificação das entidades, seus atributos e relacionamentos. Para a realização desta etapa, utilizaremos o Modelo de Entidade-Relacionamento (MER).
O MER é o modelo mais utilizado quando se realiza o projeto de banco de dados, pois possui uma semântica que possibilita o mapeamento dos objetos identificados nas fases anteriores. O MER tem por base a ideia de que o mundo real (domínio do problema) é formado por um conjunto de objetos, que podem ser denominados entidades, e pelo conjunto de relacionamentos formados entre esses objetos. O paradigma de orientação a objetos constitui-se numa evolução das técnicas e conceitos que dão sustentação ao Modelo de Entidade-Relacionamento.
Entidade: É uma “coisa” ou “objeto” que pode ser identificado de forma inequívoca em relação a todos os outros objetos contidos no domínio do problema. Uma entidade pode ser um fichário, uma pasta ou qualquer elemento sobre o qual desejamos guardar alguma informação, podendo ainda ser classificadas em entidades fortes ou fracas.
Atributo: Atributos são propriedades que caracterizam uma entidade. Os atributos são preenchidos por valores que diferenciam duas instâncias de entidade de um mesmo conjunto. Para cada atributo existe ainda um conjunto de valores possíveis.
Relacionamento: Um relacionamento constitui-se numa associação entre uma ou mais entidades. Quando, num relacionamento, estão envolvidas duas entidades, dizemos que é um relacionamento binário; quando estão envolvidas três entidades, dizemos que temos um relacionamento ternário, e assim sucessivamente. Os relacionamentos binários são mais facilmente encontrados, sendo suficiente para modelar a maioria das associações entre as entidades.
Identificando as Entidades
O processo de identificação das entidades ‘corretas’ para um modelo constitui-se numa atividade crucial para o sucesso do projeto de banco de dados. A utilização de entidades ‘erradas’ conduzirá a uma solução inadequada, que terá como conseqüência a necessidade de realização de ajustes após a implementação do banco de dados. Tais ajustes serão necessários porque o domínio do problema não foi mapeado de forma ‘correta’ para o domínio da solução, tornando a aplicação resultante inconsistente com as reais necessidades do cliente.
A complexidade dessa atividade resulta da subjetividade envolvida e da impossibilidade de validar as entidades selecionadas para um dado problema. Um erro comum dos projetistas é pensar que o primeiro conjunto de entidades identificadas é suficiente para passar à próxima fase do projeto. Ressalta-se que, para um dado problema, duas equipes podem identificar conjuntos diferentes de entidades, e, não raro, ocorrerem situações em que ambas estejam ‘corretas’.
Seguindo o exemplo, realizaremos a identificação das entidades que participarão do nosso modelo.
Manter Cadastro dos Clientes
Neste item o modelo terá uma entidade Cliente para controlar o cadastro dos clientes. Todas as informações básicas dos clientes estarão na entidade cliente.
Manter Cadastro dos Livros
Neste item o modelo terá uma entidade Livro para controlar o cadastro dos livros. Assim como na entidade cliente, todas as informações dos livros estarão na entidade livro.
Obter Relatório da Quantidade de Livros por Assunto
Neste item a nossa entidade será Assunto, pois o cliente deseja obter um relatório com a quantidade de livros por um determinado assunto. Repare que vários livros podem falar sobre o mesmo assunto e a informação do assunto não necessariamente depende do livro. Podemos ter um assunto sobre objetos distribuídos e não haver nenhum livro desse assunto na livraria, pois a livraria ainda não o adquiriu. É muito importante que o nosso modelo seja flexível para que a livraria possa ter um cadastro de assunto sem ter o livro para esse assunto.
Obter Relatório da Quantidade de Livros por Editora
Este item é idêntico ao item acima. A nossa entidade será a Editora. O nosso modelo pode ter um cadastro de editoras sem que existam livros dessa editora ou a livraria poderá, no futuro, deixar de adquirir livros dessa editora e querer manter o histórico.
Observe as entidades criadas na Figura 1.
Figura 1 - Modelo de Entidade-Relacionamento parcial para Book.net
Observando a Figura 1 acima podemos ver algumas regras para montar o nosso modelo lógico. Todas as entidades são representadas por um retângulo com o nome da entidade no singular e as letras maiúsculas e sem abreviação.
Identificando os Relacionamentos
Após a identificação das entidades, o próximo passo consiste em buscar a melhor organização estrutural para o modelo, que se dará através de relacionamentos entre as entidades. Para isso, analisaremos os seguintes requisitos:
- Controlar os livros mais vendidos e alugados;
- Controlar os livros menos vendidos e alugados;
- Controlar as reservas dos livros;
- Controlar os livros que estão alugados e o tempo de aluguel dos mesmos.
Nos itens acima, vemos que as regras de negócio são baseadas numa relação entre as informações. Para sabermos quais livros são mais vendidos ou menos alugados, o tempo de aluguel e os livros reservados, dependemos da relação entre as informações da entidade Cliente e da entidade Livro. Ou seja, quando a informação a ser obtida é dependente da relação entre as entidades damos o nome de relacionamento. Nesse caso podemos dizer que a entidade Cliente se relaciona com a entidade Livro.
A entidade Cliente tem três tipos de relacionamentos com a entidade Livro. Um relacionamento de aluguel, um de compra e um de reserva. Essas informações possuem semânticas diferentes e irão demandar operações distintas a serem realizadas sobre as entidades Cliente e Livro e, portanto, devem estar devidamente representadas no modelo, conforme pode ser observado na Figura 2.
Figura 2 – Modelo de Entidade-Relacionamento parcial para Book.net
Observando a Figura 2 acima vemos que o nosso modelo está representando de maneira correta e legível as regras de negócio entre a entidade Cliente e a entidade Livro. Podemos ver mais algumas regras para montar os relacionamentos no modelo lógico. Os relacionamentos são representados por um losango contendo o nome do relacionamento em maiúsculo, no singular e sem abreviação. Repare que o nome do relacionamento representa uma ação que o cliente está realizando em relação ao livro. A leitura é realizada da seguinte maneira: Cliente RESERVA Livro, Cliente COMPRA Livro, Cliente ALUGA Livro.
Existem outras formas de identificarmos os relacionamentos entre as entidades. Conforme dito anteriormente, relacionamentos são as informações que queremos obter, mas que dependem da relação entre as informações. No exemplo acima podemos perceber que os relacionamentos existem através de uma ação. Mas existem relacionamentos que não dependem de ação. Vendo como o nosso modelo está no momento, percebemos que duas entidades (Assunto e Editora) estão isoladas das demais.
No modelo lógico esta situação não pode ocorrer, sempre haverá relacionamentos entre as entidades. Neste caso, podemos ver que as duas entidades (Assunto e Editora) têm um relacionamento natural com a entidade Livro. Partindo da regra de negócio do nosso cliente, vemos que um livro possui editora e assunto. Veja na Figura 3 como ficou o modelo.
Figura 3 - Modelo de Entidade-Relacionamento parcial para Book.net
Observando a Figura 3 vemos que os dois novos relacionamentos também têm nomes, mas diferentemente dos outros relacionamentos, os nomes não representam uma ação. No modelo lógico mesmo quando o relacionamento não representa uma ação da regra de negócio é importante nomeá-lo para melhorar a legibilidade.
Existem dois grandes grupos de relacionamentos:
Relacionamentos Condicionais
Relacionamentos que possuem uma condição, uma qualificação para ocorrerem. Os relacionamentos condicionais são efetivamente aqueles relacionamentos em que nem todas as informações de uma entidade A estão ligados com as informações da entidade B. Dizemos que este tipo de relacionamento possui opcionalidade. No nosso modelo podemos constatar que os relacionamentos entre a entidade Cliente e a entidade Livro são condicionais, pois o cliente pode ou não alugar, reservar e comprar um livro.
Relacionamentos Incondicionais
Relacionamentos que não possuem condições, caracterizam-se por serem obrigatórios. Nos relacionamentos incondicionais, todas as informações de uma entidade estão obrigatoriamente relacionados com uma informação, no mínimo, de outra entidade. Neste caso, existe a obrigatoriedade do relacionamento entre todas as informações de uma entidade com as informações da outra entidade.
No nosso modelo podemos dizer que o relacionamento entre a entidade Livro e a entidade Assunto é obrigatório, pois não pode existir um livro sem assunto. Poderíamos até dizer que o relacionamento entre a entidade Livro e a entidade Editora também é obrigatório. Mas sabemos que pode existir um livro sem que tenha uma editora para lançá-lo. Neste caso tudo dependerá da regra de negócio do nosso cliente. No próximo artigo veremos como modelar esses dois grupos de relacionamentos.
Auto-Relacionamentos
Auto-Relacionamento é quando uma entidade possui um relacionamento com ela mesma. Observe o exemplo abaixo:
Todo cliente poderá possuir dependentes para aluguel de livros. No máximo três clientes dependentes para cada cliente titular e todos os dependentes devem ser obrigatoriamente da família do cliente.
Percebemos que existem dois tipos de clientes: titular e dependente. Esta modificação na regra de negócio implica em um auto-relacionamento para a entidade cliente, conforme demonstra a Figura 4.
Figura 4 – Modelo de Entidade-Relacionamento parcial para Book.net
Identificando os Atributos das Entidades
Agora que nosso modelo já possui as entidades e os relacionamentos, podemos identificar os atributos das entidades. Para isso, devemos voltar à análise de requisitos nos itens que falam sobre as informações dos clientes, livros, editora e assunto. Vamos ver os exemplos abaixo:
- O cliente pessoa física, ao se cadastrar, deve informar os seguintes dados obrigatórios: nome, identidade e/ou CPF, data de nascimento, endereço e pelo menos um telefone de contato. As informações opcionais são: e-mail, home-page pessoal e outros tipos de telefones.
- O cliente pessoa jurídica ao se cadastrar deve informar os seguintes dados obrigatórios: CNPJ, razão social, endereço e pelo menos um telefone de contato. As informações de e-mail, home-page e outros telefones não são obrigatórias.
Nos itens acima podemos ver quais são os atributos da entidade Cliente. Repare que em nenhum momento nos preocupamos com informações como código do cliente e matrícula. Isso significa que na regra de negócio a informação código não é importante. Como estamos no modelo lógico, devemos seguir fielmente as informações passadas pelo nosso cliente, pois a existência do atributo código seria uma forma física de manter o controle dos dados.
Figura 5 – Modelo de Entidade-Relacionamento parcial para Book.net
Todos os atributos com exceção de ENDERECO e TELEFONE são atributos atômicos, ou seja, são atributos que não podem ser divididos em outros atributos. Já os atributos ENDERECO e TELEFONE são chamados de atributos compostos, pois podemos dividí-los em atributos atômicos que façam sentido na regra de negócio do cliente. O atributo ENDERECO poderá ser dividido em RUA, BAIRRO, CIDADE e assim por diante. O mesmo vale para TELEFONE, que poderia ter DDD, NUMERO e RAMAL. No entanto, se realizássemos a divisão nos atributos prejudicaríamos a legibilidade do modelo.
- Ao cadastrar um livro as seguintes informações obrigatórias são preenchidas: ISBN, nome do livro, editora, autor, ano de publicação, assunto, se é para compra ou aluguel, se é nacional ou importado e quantidade que a livraria possui. As informações opcionais são: preço de venda, preço de aluguel, preço de renovação de aluguel.
No item acima, a identificação dos atributos pode ser feita da mesma forma. Os atributos ISBN, nome, autor, ano publicação, aluguel/compra, nacional/importado, quantidade, preço de venda, preço de aluguel, preço da renovação de aluguel são da entidade Livro. O atributo nome da editora pertence à entidade Editora e o atributo Assunto pertence à entidade Assunto. Veja, na Figura 5, como ficou o nosso modelo com os atributos em todas as entidades.
Os relacionamentos, de forma idêntica às entidades, possuem atributos. A identificação de atributos para relacionamentos será vista no próximo artigo.
Figura 6 - Mo delo de Entidade-Relacionamento parcial para Book.net
Conclusão
Nesta primeira parte do artigo vimos como começar a criar um modelo do nosso projeto de banco de dados. Aprendemos a identificar as entidades, os relacionamentos e os atributos a partir da análise de requisitos e os padrões da criação do modelo. Vimos também a necessidade de se criar um projeto de banco de dados seguindo exatamente os passos aqui descritos. O software utilizado para modelagem foi o VISIO 2000 Professional. Para maiores detalhes deste software, visite o site da Microsoft.
Na próxima edição continuaremos com a criação do nosso modelo de dados. Falarei sobre Cardinalidades, Atributos dos Relacionamentos, Tipos de Atributos, Especialização, Generalização, Entidades fracas e fortes.
