Na edição anterior vimos como começar um modelo de um projeto de banco de dados. Aprendemos a identificar as entidades, os relacionamentos e os atributos a partir da análise de requisitos feito com o cliente e alguns dos padrões para criação do modelo. Vimos também a necessidade de se criar um projeto de banco de dados seguindo exatamente os passos descritos na edição anterior.
Nesta edição darei continuidade à construção do modelo lógico do nosso projeto de banco de dados. Veremos como identificar atributos identificadores que são responsáveis pela identificação de uma determinada informação, modelar as cardinalidades e como identificá-las, também veremos os atributos dos relacionamentos, mais sobre os tipos de atributos e sobre especialização e generalização.
Atributos Identificadores
Atributos identificadores são os atributos que tem a finalidade de identificar uma determinada informação. Mesmo no modelo lógico sempre devemos indicar um atributo que seja o responsável por identificar a informação única de uma determinada entidade e que seja obrigatório e não tenha valores repetidos. Devemos prestar bastante atenção para não confundir esse atributo com chave primária, pois ainda estamos no modelo lógico. No modelo físico esse atributo poderá ser ou não uma chave primária. Vamos observar o nosso modelo e ver na entidade Cliente qual atributo poderá ser um identificador da informação, lembrando que ele deve ser obrigatório na regra de negócio e que não tenha valores repetidos.
O atributo Nome poderia ser esse identificador, mas sabemos que é raro duas ou mais pessoas terem o mesmo nome e além do mais, quando for um cliente pessoa jurídica esse atributo não será obrigatório, pois a entidade tem o atributo Razão Social. O mesmo vale para os atributos Identidade, Cpf, Data Nascimento que só serão preenchidos para pessoas físicas e o atributo Cnpj que é para pessoa jurídica. Os demais atributos não são obrigatórios. Depois dessa análise, percebemos que não temos nenhum atributo na entidade Cliente que possa servir como identificador para uma única informação de um determinado cliente. Quando isso ocorre, nos é permitido criar um novo atributo que seja o identificador. Esse novo atributo seria um código qualquer, apenas para servir como identificador. Lembre-se que na edição anterior eu descrevi a seguinte afirmativa:
Que em nenhum momento deveríamos nos preocupar com informações como código do cliente, matrícula, etc, pois isso significava que na regra de negócio do cliente, a informação código do cliente não é importante, ou seja, o cliente não possui um código próprio e que 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 controlar os clientes.
Essa afirmativa deve ser mantida sempre, mas no caso do atributo identificador, quando não podemos encontrar um como aconteceu na entidade Cliente, podemos inserir um atributo que seja um código sem que ele esteja mencionado na regra de negócio. Veja na figura 1 como ficou a entidade Cliente com esse novo atributo:
FIGURA 1 - Modelo de Entidade-Relacionamento parcial para Book.net
Observando a figura acima, podemos ver o novo atributo Código na entidade Cliente. Lembrando que esse atributo só foi inserido para servir como identificador de um único cliente. No modelo físico ele poderá ser ou não uma chave primária. Veja na figura 2 os atributos identificadores das demais entidades:
FIGURA 2 - Modelo de Entidade-Relacionamento parcial para Book.net
Observando a figura acima, podemos ver os atributos identificadores das entidades Livro Editora e Assunto. Na entidade Livro o atributo identificador é o Isbn que é o código universal dos livros, na entidade Editora será o atributo Nome e na entidade Assunto o atributo Assunto. Todos esses atributos são únicos e obrigatórios.
Identificando Cardinalidades
Cardinalidade ou também conhecido como Grau de Relacionamento representa a quantidade de ocorrências (informação) de uma entidade que está associada à uma outra entidade através do relacionamento. É através da cardinalidade que definimos se o relacionamento é obrigatório ou não, se na implementação do banco de dados e até mesmo da aplicação haverá Master/Detail. Descobriremos também que através da cardinalidade, aparecão novos atributos no nosso modelo de banco de dados. Para começar vamos observar o relacionamento de compra entre a entidade Cliente e a entidade Livro do nosso modelo. Ao vermos como nosso modelo está atualmente, dizemos que o cliente compra livros e os livros são comprados pelos clientes. Mas como faremos para modelar a quantidade que os clientes compram os livros e a quantidade de livros que são comprados pelos clientes? É através da cardinalidade. A cardinalidade como nos passos anteriores para modelagem do projeto de banco de dados, deve seguir as regras de negócio do nosso cliente ou se não estiver explícito na regra de negócio ser o mais fiel ao mundo real da empresa do cliente. Por exemplo, imaginemos que a livraria tenha 100 clientes e que em um determinado dia nenhum cliente compra livro e no outro dia vários clientes compram livros. Com essa informação, podemos perceber que pode existir clientes cadastrados sem que nenhum tenha comprado um livro e existir livros cadastrados sem que não tenham sido comprados por nenhum cliente.
Então podemos dizer que o Grau de Relacionamento entre a entidade Cliente e a entidade Livro no Relacionamento COMPRA é de no mínimo “0” (zero) cliente compra um livro e no máximo “N” (indeterminado) clientes compram livros. À princípio pode parecer bastante complicado identificar o Grau de Relacionamento entre entidades, mas existe uma maneira bastante simples que facilita essa identificação. Trata-se do relacionamento de conjuntos que víamos nas aulas de matemática. Veja na figura 3 como fica o relacionamento de conjuntos.
Clientes Livros
FIGURA 3 – Relacionamento dos conjuntos Clientes e Livros
Observando a figura acima, podemos entender melhor como identificamos o Grau de Relacionamento entre as entidades. Como no exemplo anterior, a cliente Claudia está cadastrada mas não comprou nenhum livro e o livro de Visual Basic não foi comprado por nenhum cliente seja pela regra de negócio da empresa ou simplesmente como funciona no mundo real da livraria. Agora podemos modelar a cardinalidade no relacionamento COMPRA entre as entidades Cliente e Livro. Veja a figura 4 abaixo:
FIGURA 4 - Modelo de Entidade-Relacionamento parcial para Book.net
Observando a figura acima, vemos como ficou o nosso modelo com o Grau de Relacionamento entre as entidades Cliente e Livro. Ao lermos o relacionamento fazemos da seguinte maneira no sentido da entidade Cliente para entidade Livro: No mínimo “0” cliente compra um livro e no máximo “N” clientes compram um livro e no sentido da entidade Livro para entidade Cliente: No mínimo “0” livro é comprado por um cliente e no máximo “N” livros são comprados por clientes.
O Grau de Relacionamento mínimo indicará se o relacionamento é obrigatório ou não. Como temos Grau de Relacionamento de mínimo “0” em ambos os lados das entidades, significa que podemos ter clientes e livros cadastrados sem se relacionarem uns com os outros. Ou seja, na implementação do nosso banco de dados esse relacionamento não será obrigatório. O valor “N” da cardinalidade máxima significa que desconhecemos o limite de ocorrências desse relacionamento.
Nos relacionamentos de aluguel e reserva de livros o Grau de Relacionamento será o mesmo. Veja a figura 5 abaixo:
FIGURA 5 - Modelo de Entidade-Relacionamento parcial para Book.net
Observando a figura acima, vemos como ficou o nosso modelo com o Grau de Relacionamento de todos os relacionamentos entre as entidades Cliente e Livro. Como descrito antes, os três relacionamentos não são obrigatórios.
Na regra de negócio do nosso cliente, um cliente só pode alugar no máximo três livros de uma só vez. Você pode estar se perguntando porque não coloquei a cardinalidade máxima com o valor “3” ao invés de “N”? Simplesmente porque o valor “3” se refere a um aluguel específico, mas o cliente poderá alugar outros livros em outros dias. Um fato muito importante que devemos nos preocupar quando vamos modelar a cardinalidade, é que o tempo é muito importante. Se colocassemos o valor “3” na cardinalidade máxima estaríamos dizendo que ao alugar o terceiro livro, o cliente não poderá mais alugar nenhum livro. Como ao longo do tempo ele poderá alugar outros livros, então devemos permitir que ele possa alugar esses outros livros colocando a cardinalidade máxima com o valor “N”. Mesmo assim você pode estar se perguntando como modelar essa regra de negócio onde o cliente só poderá alugar 3 livros por vez? Essa regra nós veremos mais adiante quando falarei sobre Restrição de Integridade (RI).
Agora vamos observar como ficou o nosso modelo de banco de dados com o Grau de Relacionamento nos relacionamentos das outras entidades. Veja as figuras abaixo:
FIGURA 6 - Modelo de Entidade-Relacionamento parcial para Book.net
Observando a figura acima, vemos que o Grau de Relacionamento em relação ao Auto-Relacionamento da entidade Cliente ficou diferente dos outros relacionamentos. Percebemos pelo sentido da leitura do relacionamento que no mínimo um cliente titular qualquer tem “0” dependente e no máximo “3” dependentes e no sentido inverso, no mínimo um dependente qualquer pertence à “1” cliente titular e no máximo à “1” cliente titular.
Como já vimos antes, os clientes não são obrigados a terem dependentes, pois a cardinalidade mínima é “0”, porém, quando existir um dependente ele terá que pertencer à um único titular obrigatoriamente, pois tanto a cardinalidade mínima como à máxima possui valor “1”. Um cliente só poderá ter no máximo 3 dependentes, porque essa é a regra de negócio do nosso cliente. Lembra da análise de requisitos da edição anterior. Veja ela abaixo:
Todo cliente poderá possuir clientes dependentes para aluguel de livros. No máximo 3 clientes dependentes para cada cliente titular e todos os dependentes devem ser obrigatoriamente da família.
No momento da implementação do nosso banco de dados, deveremos tomar muito cuidado com esse auto-relacionamento, pois um mesmo cliente não pode ser dependente de dois ou mais titulares. Essa modelagem da cardinalidade é diferente da que fizemos para os relacionamentos da entidade Cliente e Livro, pois aqui o tempo não conta. Quando um cliente possuir 3 dependentes não poderá ter outros.
FIGURA 7 - Modelo de Entidade-Relacionamento parcial para Book.net
Observando a figura acima, vemos que o Grau de Relacionamento em relação ao relacionamento da entidade Livro com as entidades Editora e Assunto também ficaram diferentes dos outros relacionamentos. Percebemos pelo sentido da leitura do relacionamento que um livro possui no mínimo “1” editora e no máximo “1” editora e que uma editora possui no mínimo “0” livro e no máximo “N” livros. Isso significa que pode existir uma editora sem ter relacionamento com nenhum livro, mas um livro deve estar obrigatoriamente relacionado à uma editora. O mesmo ocorre em relação ao assunto, que não precisa estar cadastrado e ter relação com um livro, mas o livro deve estar relacionado com um assunto obrigatoriamente.
Como podemos ver, identificar o Grau de Relacionamento entre as entidades não é uma tarefa difícil, basta olharmos com atenção para as regras de negócio ou até mesmo para como a empresa dos nossos clientes funciona que será fácil a modelagem das cardinalidades. Vimos que a cardinalidade mínima indica se o relacionamento é obrigatório ou não e isso será de extrema importância na implementação de um banco de dados. Com a cardinalidade máxima podemos perceber a existência de Master/Detail entre as informações.
Identificando Atributos dos Relacionamentos
Podemos dizer que a cardinalidade é apenas o primeiro passo para a completude do relacionamento entre as entidades. É através da cardinalidade que perceberemos que novos atributos surgirão e até mesmo novas entidades. Para melhor entendimento vejamos abaixo os tipos de Graus de Relacionamentos existentes:
- Relacionamento Um-para-Um:Neste grau de relacionamento, cada elemento (informação) da entidade relaciona-se com um e somente um elemento de outra entidade.
- Relacionamento Um-para-Muitos:Este grau de relacionamento é o mais comum no mundo real. Podemos pegar como exemplo o relacionamento entre a entidade Livro e a entidade Editora, onde cada elemento da entidade Livro relaciona-se com um e somente um elemento da entidade Editora, mas cada elemento da entidade Editora pode relacionar-se com um ou mais elementos da entidade Livro.
- Relacionamento Muitos-para-Muitos:Este grau de relacionamento é o mais complicado dos três. Podemos pegar como exemplo o relacionamento em que o cliente aluga um livro. Como vimos antes, um cliente pode alugar nenhum livro ou vários livros ao longo do tempo. Vamos imaginar que um cliente alugue hoje o livro de Delphi e na semana que vem alugue o mesmo livro. Bem, olhando por esse lado percebemos que as informações do cliente e do livro como nome do cliente e nome do livro vão se repetir. Como vimos no início da edição, toda entidade deve ter um atributo que tenha valor único para ser um identificador das informações. Nos relacionamentos desse tipo isso também acontece. Sempre que existir relacionamentos Muitos-para-Muitos, certamente será relacionamentos ao longo do tempo e por isso deve existir um atributo com valor único que identifique um relacionamento único. Nesse caso e na maioria dos outros um atributo que represente a data ou data/hora é o atributo que identificará o relacionamento e como nas entidades esse atributo será obrigatório. Por ser um atributo específico para o relacionamento, ele é chamado de atributo do relacionamento. Para identificarmos de maneira fácil os relacionamentos ao longo do tempo teremos que voltar aos relacionamentos entre conjuntos como vimos no início da edição. Veja na figura 8 como fica o relacionamento de conjuntos:
Clientes Aluga Livros
FIGURA 8 – Relacionamento dos conjuntos Clientes e Livros
Observando a figura acima, podemos ver como acontece no mundo real. Os clientes João e Claudia alugaram os mesmos livros em datas diferentes. Podemos ver como o atributo que indica a data que ocorreu o aluguel é importante neste tipo de relacionamento. Veja na figura 9 como fica modelado esse novo atributo:
FIGURA 9 - Modelo de Entidade-Relacionamento parcial para Book.net
Observando a figura acima, podemos ver que o atributo do relacionamento ALUGA está modelado igual ao atributo NOME da entidade Cliente.Ambos são obrigatórios e únicos. OBS: Caso não seja possível colocar apenas um atributo para identificar o relacionamento, pode-se colocar mais de um atributos desde que seus valores em conjunto sejam únicos. Por exemplo, eu poderia ter colocado um atributo para guardar a DATA e outro para guardar a HORA. Isso também vale para as entidades.
Agora vamos observar as seguintes regras de negócios abaixo:
5 - 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, o cliente deverá pagar 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.
10 - 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.
Analisando a primeira regra de negócio, percebemos que no momento do aluguel de qualquer livro, outras informações são necessárias. Podemos identificar como sendo atributos desse relacionamento, o período de aluguel, a data de devolução do livro e o valor de multa caso o cliente tenha passado do tempo máximo permitido. Com isso, podemos ver que nos relacionamentos Muitos-para-Muitos, não necessariamente deverá conter apenas os atributos que identifique o relacionamento e sim também existir tantos atributos forem necessários para contemplar a regra de negócio do cliente.
Analisando a segunda regra de negócio, percebemos um novo atributo neste relacionamento que é a promoção que o cliente pode ganhar pelo número de compras de livros que le vez na livraria. Veja na figura 10 como ficou o relacionamento ALUGA com as modificações:
FIGURA 10 - Modelo de Entidade-Relacionamento parcial para Book.net
Observando a figura acima, podemos ver todos os atributos do relacionamento ALUGA. Você deve estar se perguntando porque não foi colocado um atributo para a data de renovação e somente para a data de entrega do aluguel. Isso é porque uma renovação é um novo aluguel. Lembre-se que no modelo físico, esse relacionamento se tornará uma entidade (tabela). Veja nas figuras abaixo como ficaram os relacionamentos COMPRA e RESERVA com seus atributos:
FIGURA 11 - Modelo de Entidade-Relacionamento parcial para Book.net
Observando a figura acima, podemos ver que o relacionamento COMPRA ficou igual ao relacionamento ALUGA, tendo um atributo obrigatório que identifica um relacionamento único e um outro atributo inerente à regra de negócio.
FIGURA 12 - Modelo de Entidade-Relacionamento parcial para Book.net
Tipos de Atributos
Como vimos na edição anterior, existem vários tipos de atributos que são os atômicos, compostos, mono-valorados, multi-valorados, opcionais e mandatórios. Na edição anterior descrevi o que são os atributos atômicos e compostos e nessa edição falarei sobre os demais tipos de atributos. Vamos ver visão geral de cada tipo de atributo.
- Atômico – Como visto na edição anterior, os atibutos atômicos são aqueles que não podem ser divididos em sub-atributos. Como exemplo temos os atributos Nome, Identidade e E-mail da entidade Cliente.
- Composto – Como visto na edição anterior, os atributos compostos são aqueles que podemos dividi-los em atributos atômicos que façam sentido na regra de negócio do cliente. Como exemplo temos os atributos Telefone e Endereco da entidade Cliente.
- Mono-Valorados – Os atributos mono-valorados são aqueles que possui apenas um domínio (valor) dentro da informação como um todo. Como exemplo temos os atributos Identidade e Cpf da entidade Cliente. Um cliente possui apenas uma identidade e um cpf, então os atributos só terão um único valor ou domínio de valor.
- Multi-Valorados – Os atributos muti-valorados são aqueles que possui mais de um domínio de valor dentro da informação como um todo. Como exemplo temos os atributos E-mail, Telefone, Home-Page da entidade Cliente e o atributo Autor da entidade Livro. Podemos observar de forma clara que um cliente pode ter mais de um e-mail, mais de um telefone e mais de uma homepage e um livro pode ter mais de um autor. Esses atributos para um único cliente ou livro poderá conter mais de uma informação, por isso eles são chamados de atributos multi-valorados.
- Opcionais – Os atributos opcionais são aqueles que não são obrigatórios possuir um valor. Podemos ter como exemplo os atributos E-mail, Home-Page da entidade Cliente. Existem também atributos que são opcionais através de condições. Por exemplo, os atributos Cnpj e Razao Social da entidade Cliente só serão obrigatórios caso o cliente seja pessoa jurídica e o atributo Preço Aluguel da entidade Livro só será obrigatório quando for um livro para aluguel.
- Mandatórios – Os atributos mandatórios são todos aqueles atributos que são obrigados à possuir valores. Como exemplo podemos ver os atributos Codigo da entidade Cliente e os atributos Isbn, Nome e Ano Publicação da entidade Livro.
Para identificar os tipos de atributos, somente pela regra de negócio. Agora que você já conhece os tipos de atributos, deve estar se perguntando como modelar esses tipos no nosso modelo de banco de dados? Em primeiro lugar os tipos Atômico e Composto não são modelados. Eles serão descritos no dicionário de dados do nosso modelo de banco de dados. Mais para frente falarei sobre o dicionário de dados. Os demais tipos de atributos são modelados e agora veremos como:
É através da cardinalidade que indicaremos os tipos de atributos no nosso modelo de banco de dados. Os tipos de atributos Opcionais e Mandatórios serão através da cardinalidade mínima e os tipos de atributos Mono-Valorados e Multi-Valorados serão através da cardinalidade máxima. Veja a figura 13 como ficam alguns atributos da entidade Cliente com as cardinalidades.
FIGURA 13 - Modelo de Entidade-Relacionamento parcial para Book.net
Observando a figura acima, podemos ver que os atributos da entidade Cliente possui cardinalidades para indicar seus tipos. A cardinalidade nos atributos é de caráter opcional, ou seja, você só coloca se quiser detalhar mais o seu modelo, mas de qualquer maneira os tipos de atributos e suas cardinalidades devem estar no dicionário de dados. Veja na figura 14 as cardinalidades dos atributos das demais entidades.
FIGURA 14 - Modelo de Entidade-Relacionamento parcial para Book.net
Também não podemos esquecer que os atributos compostos, nós podemos decompô-los em sub-atributos caso seja importante para a visualização do modelo, senão, podemos deixá-los de forma composta e no dicionário de dados dizer em quais atributos ele é composto.
Especialização e Generalização
Especialização e Generalização serve tanto para a modelagem das regras de negócio como para deixar o modelo de banco de dados mais fácil de se entender as funcionalidades do mundo real. Quando começamos a modelar as entidades, ficamos atentos as suas características como um todo e às vezes não percebemos que por trás do todo existe partes específicas que poderiam ser modeladas de forma a atender melhor as regras de negócio ou até mesmo para compreendermos melhor como as informações são trabalhadas no mundo real. Ao olharmos para uma entidade e vermos suas regras de negócio com bastante atenção, podemos perceber que existem sub-entidades que podem ser modeladas como sendo entidades únicas. Sempre devemos nos atentar para essas entidades e tentar enxergar sua importância para o modelo de banco de dados, pois nelas podem conter diferentes formas de modelar as regras de negócio. Vejamos a seguinte regra de negócio abaixo:
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.
Observando a regra de negócio acima, percebemos que existem dois tipos de clientes que são pessoas físicas e pessoas jurídicas e que as pessoas jurídicas podem ser universidades, centros educacionais ou qualquer curso. Olhando como o nosso modelo está atualmente, vemos que na entidade Cliente está modelado todos os atributos que representam as informações de uma pessoa física e de uma pessoa jurídica juntos. Mas o que isso vem a acarretar ao nosso modelo? 1) Se cada tipo de cliente tiver uma forma diferente de relacionamento com as outras entidades, isso poderia ficar complicado de se entender no modelo. Por exemplo, um cliente pessoa jurídica não tem dependentes, pois isso é uma característica de pessoa física. Outro exemplo seria que uma pessoa jurídica teria uma quantidade mínima de livros para alugar e comprar. 2) A modelagem fica pobre por não mostrar todas ou as principais características de um cliente e uma modelagem visual é de extrema importância que tanto os usuários (cliente) como os analistas e desenvolvedores possam enxergar as funcionalidades do mundo real no modelo.
Nesses exemplos podemos observar que para modelar fielmente as regras de negócio e para termos uma compreensão melhor do mundo real através do modelo de banco de dados é necessário modelarmos todas ou as principais características de uma entidade e a Especialização e Generalização nos ajuda em muito. Veja na figura 15 como o modelo ficou com a especialização da entidade Cliente.
FIGURA 15 - Modelo de Entidade-Relacionamento parcial para Book.net
Observando a figura acima, podemos ver que com a especialização da entidade Cliente fica mais fácil o entendimento das características de um determinado cliente. Agora a entidade Cliente é uma entidade genérica e suas entidades (sub-entidades) são especializações, assim como a entidade Pessoa Juridica é genérica para as entidades Universidade, Centro Educacional e Curso.
O nome Especialização é dado quando o sentido da leitura é feita a partir da entidade genérica e o nome Generalização é quando o sentido da leitura é inversa, pois assim como fizemos com a entidade Cliente que "desmembramos" em outras entidades, poderíamos ter feito o contrário. Se no início tivéssemos modelado as entidades Pessoa Fisica e Pessoa Juridica, poderíamos ter criado a entidade Cliente fazendo uma generalização.
Na regra de negócio acima estava fácil a identificação da especialização, mas nem sempre é assim, fazendo com que tenhamos dúvidas se podemos ou não especializar uma entidade. Para identificar a especialização de forma correta, devemos fazer uma simples pergunta "É PARTE DE". Ao perguntarmos se uma pessoa física é parte de um cliente e a resposta for verdadeira, então temos uma especialização. Uma vez feita a especialização da entidade Cliente, agora devemos fazer uma distribuição dos atributos em suas respectivas entidades. Por exemplo, os atributos referentes à uma pessoa física ficará na entidade Pessoa Fisica e o mesmo para os atributos de pessoa jurídica. Veja na figura 16 como ficou a distribuição dos atributos da entidade Cliente.
FIGURA 16 - Modelo de Entidade-Relacionamento parcial para Book.net
Observando a figura acima, podemos ver que os atributos da entidade Cliente agora estão nas suas respectivas entidades, respeitando assim a regra de negócio.
Vemos também que as novas entidades não possui o atributo identificador. Isso se dá pelo seguinte motivo: Podemos observar que os atributos que estão na entidade Cliente são atributos genéricos para as entidades especializadas, ou seja, as entidades Pessoa Fisica, Pessoa Juridica, Universidade, Centro Educacional e Curso possuem os mesmos atributos da entidade Cliente, por isso não é necessário repeti-los novamente. Caso uma dessas novas entidades necessitasse de um outro atributo identificador, deveríamos criá-lo. Não façam analogia com a herança de orientação à objetos, pois esse é um modelo para banco de dados relacionais. Repare também que as entidades especializadas da entidade Pessoa Juridica não possuem atributos. Isso porque só modelamos essas entidades para um entendimento maior de uma pessoa jurídica no mundo real, pois na regra de negócio não tem nada especificado à essas entidades.
Tipos de Especialização
Agora que modelamos as especializações da entidade Cliente, podemos complementar nosso modelo indicando qual o tipo de especialização está modelado. Existem três tipos de especialização que podemos modelar e são essas:
- Total (T): Esse tipo de especialização é quando modelamos todas as características de uma entidade. No nosso modelo podemos dizer que a especialização das entidades Cliente e Pessoa Juridica é total, pois todas as suas características estão no modelo.
- Parcial (P): Esse tipo de especialização é quando apenas modelamos as principais características de uma entidade, deixando algumas menos importantes de fora do modelo. Mas a característica que ficar de fora deve constar no dicionário de dados.
- Exclusiva (E): Esse tipo de especialização indica que uma entidade possui uma única característica de uma única vez, ou seja se um cliente é uma pessoa física ele não pode ser uma pessoa jurídica ao mesmo tempo e vice-versa ou um livro que não pode ser nacional e importado ao mesmo tempo. Caso venha ocorrer de uma entidade ter características diferentes ao mesmo tempo, não indicamos a exclusividade.
Veja na figura 17 como ficou modelado a especialização completa da entidade Cliente e na figura 18 a especialização da entidade Livro, pois um livro pode ser Nacional ou Importado.
FIGURA 17 - Modelo de Entidade-Relacionamento parcial para Book.net
FIGURA 18 - Modelo de Entidade-Relacionamento parcial para Book.net
Conclusão
Nesta edição aprendemos outras técnicas que nos ajudam a modelar de forma lógica as informações do mundo real, tornando o entendimento claro das suas funcionalidades. Vimos a importância dos atributos identificadores e principalmente das cardinalidades que indicarão a necessidade ou não de novos atributos e novas entidades. Também vimos os tipos dos atributos e como a cardinalidade nos ajuda a identificar esses tipos e aprendemos como a especialização e generalização pode ser uma técnica poderosa para a compreensão das características de uma entidade no mundo real.
Na próxima edição darei continuidade no nosso modelo lógico e mostrarei as Restrições de Integridade (RI), as Regras de Derivação (RD), agregação, entidades fortes e fracas e dicionário de dados.
