Análise e projeto de sistemas - Regilan€¦ · Esse modelo é bastante popular e freqüentemente...

Preview:

Citation preview

Análise e projeto de

sistemasPROF. REGILAN SILVA

Modelo de

dados

Modelo de Banco de Dados

Um modelo de banco de dados é um modelo lógico de

representação dos dados. Em um modelo, não temos

que nos preocupar com questões de implementação

física, formato dos dados, etc.

No mundo real, existe todo tipo de modelos:

Modelos Econômicos

Modelos Estatísticos

Simuladores de Vôo

Planta de uma casa

Mapa de estradas

Modelo de Banco de Dados

Assim como existem modelos para o mundo real, também existem

modelos específicos para a representação de dados ou da estrutura de

dados em um banco de dados. O mais famoso e utilizado é o Modelo

Relacional.

Como a maior parte dos sistemas de gerência de banco de dados

atuais, baseia-se no modelo relacional. Devido a isso, esses sistemas são

chamados de sistemas de gerência de banco de dados

relacional(SGBDR)

Modelo Entidade-Relacionamento

Durante a fase de Análise que acontece antes da implementação do Banco de Dados, é comum a utilização de uma representação gráfica das entidades envolvidas e como elas se relacionam.

Esse modelo é bastante popular e freqüentemente utilizado para o projeto conceitual dos dados, que posteriormente servirá de base para o projeto físico(modelo relacional).

O modelo Entidade-Relacionamento é baseado em símbolos gráficos que representam as Entidades e seus atributos, e os relacionamentos entre as entidades.

Devido à sua simplicidade, tornou-se um recurso quase que obrigatório no projeto de banco de dados relacionais.

Modelo Entidade-Relacionamento

A estrutura lógica global de uma base de dados pode ser expressa

graficamente por um diagrama chamado entidade-relacionamento,

que consiste nos seguintes componentes:

Entidades

Atributos

Relacionamentos

Entidade

O Conceito fundamental da abordagem ER é a Entidade

Uma Entidade é um conjunto de objetos sobre os quais se deseja manter informações no banco de dados.

Em geral, utiliza-se um substantivo no singular para identificá-lo: Aluno, Curso, Departamento, etc, e cada entidade deve representar uma única “coisa”.

No MER(modelo entidade-relacionamento), as entidades são representadas por retângulos dentro dos quais deve ser colocado o nome da entidade.

Curso Disciplina Aluno

Atributos

Os atributos são propriedades que descrevem cada membro

de um conjunto de entidades.

Exemplos:

Entidade: Cliente

Atributos: Nome, Endereco, RG, CPF.

Entidade: Voo

Atributos: numero,saída,piloto,data,destino.

Entidade: Carro

Atributos: ano, cor, modelo, marca, etc.

Os Atributos são representados por um círculo e ligados a uma

entidade.

Atributos

O atributo identificador ou chave primária (no modelo relacional)

representa um código único que identifica uma entidade. Exemplo: Em

um cadastro de Fornecedor, o atributo CNPJ identifica um fornecedor

específico de uma entidade Fornecedor.

Este atributo é apresentado de forma destacada (sublinhado,

preenchido, negrito)

Representação:

Fornecedor

CNPJ

RAZÃO

SOCIAL

Atributos

Devido a questão de estética os atributos são apresentados também

como uma lista sequencial, indicando o atributo identificador(chave

primária) em sublinhado ou em negrito.

Exemplo:

Fornecedor(CNPJ, Razão Social, Nome Fantasia, Logradouro, Bairro, ...)

Relacionamentos

É através dos relacionamentos que conseguimos ligar a informação presente em entidades de alguma forma relacionadas.

Um relacionamento corresponde a uma ligação lógica entre entidades indicando a forma como as duas entidades se relacionam.

É através dos relacionamentos que os SGBDR permite realizar por exemplo as seguintes buscas:

Quem é chefe de quem?

Que funcionários pertencem a que departamentos?

Que funcionários estão envolvidos em mais de um projeto?

Quas as faturas associdas a que fornecedores.

Relacionamentos

Os relacionamentos entre as entidades são representados por uma linha

que une as duas entidades.

O nome do relacionamento é em geral apresentado como um tempo

verbal, uma vez que simboliza a “ação” estabelecida entre as entidades

envolvidas.

Alunos DisciplinaFreqüenta

Relacionamentos

Existe uma outra representação alternativa e que em geral é a mais

utilizada, na qual o relacionamento entre as entidades é expresso através

de um losango dentro da qual é colocado o nome do relacionamento.

Alunos DisciplinaFreqüenta

Cardinalidade

Um importante conceito em um relacionamento é o número de

ocorrências que podem estar associadas a um registro da outra

entidade.

Este conceito melhora o conhecimento sobre as políticas e regras dos

Negócios, consistindo de números (cardinais) colocados ao lado do

nome do relacionamento.

As cardinalidades mais comuns são:

Relacionamento 1:1 - um-para-um

Relacionamento 1:N - um-para-muitos

Relacionamento M:N – muitos-para-muitos

Cardinalidade

Desta forma, os números colocados ao lado do nome do

relacionamento são chamados de cardinalidade do relacionamento e

dimensionam as políticas de Negócio que envolvem os dados.

A cardinalidade define, portanto, o número de ocorrências de uma

entidade que pode estar envolvido em um relacionamento, sendo útil

para extrair daí regras de consistência e integridade dos dados.

Cardinalidade

Considere o exemplo: “Na minha empresa cada funcionário

pertence a um único departamento, mas cada departamento

pode ter vários funcionários”

Como existe um relacionamento entre os funcionários e o

departamentos, esse relacionamento poderá ser representado da

seguinte forma:

Departamento FuncionárioPossui

Cardinalidade

Porém no enunciado cada departamento pode ter vários funcionários,

enquanto um funcionário pode pertencer a apenas um departamento.

Isso quer dizer que as entidades formam um relacionamento 1:N.

Para representar as cardinalidades utilizamos os símbolos 1 ou N nas

entidades de destino. Veja o exemplo:

Departamento FuncionárioPossui1 N

Cardinalidade um-para-um (1:1)

Indica que uma única ocorrência de uma entidade pode se relacionar com

apenas uma única ocorrência de outra entidade. Este tipo de

relacionamento é bastante raro (no mundo dos negócios).

Exemplo: Em uma lan-house, cada cliente (1) utiliza uma mesa com

computador (1).

Cardinalidade um-para-um (1:1)

Neste caso um determinado cliente, utiliza um(e somente um)

computador ao mesmo tempo. Essa situação poderá ser representada

da seguinte forma:

Cliente Computadorutiliza

1 1

Cardinalidade um-para-um (1:1)

Outro exemplo: No IFBA um professor (e somente um) coordena um (e

somente um) curso, ou seja, o mesmo professor não pode coordenar

mais de um curso e um curso não pode ser coordenado por mais de um

professor.

Professores Cursoscoordena

1 1

Cardinalidade um-para-muitos (1:N)

Indica que uma ocorrência de uma entidade pode se relacionar com

muitas ocorrências de outra entidade.

No entanto, a recíproca não é verdadeira. Este tipo de relacionamento é

muito comum (no mundo dos negócios).

Por exemplo: FUNCIONÁRIO (1) possui (N) DEPENDENTE

Cardinalidade um-para-muitos (1:N)

Dessa forma um funcionário pode possuir vários dependentes; mas cada

dependente pertence a apenas um funcionário.

Outro exemplo: No IFBA um curso é cursado por n alunos, porém um

aluno só pode cursar um(e somente um curs0)

Funcionario DependentePossui1 N

Alunos CursosCursam

N 1

Cardinalidade muitos-para-muitos(N:M)

Indica que várias ocorrências de uma entidade pode se relacionar com

muitas ocorrências de outra entidade.

Por exemplo: Pedido(M) e Produtos(N)

Pedido

Possui

Produto

M N

Cardinalidade muitos-para-muitos(N:M)

Outro exemplo: No IFBA existe uma biblioteca onde os livros podem ser

reservadospara vários alunos. Dessa forma, existe um relacionamento N:M entre

as entidades Livros(N) e Alunos(M).

Livros Reservam AlunosM N

Dicionário de dados

As tabelas possuem atributos, como nome da tabela, nome dos campos

e o tipo de dados que os campos armazenam. Portanto, torna-se

necessário um local estruturado para manter todos estes detalhes.

O dicionário de dados é um local onde o Analista/Projetista de banco de

dados relaciona as informações de cada tabela da base de dados.

Dicionário de dados

ENTIDADE: CLIENTE

ATRIBUTO DESCRIÇÃO RELACIONAMENTO TIPO DE DADO

PK COD_CLI Código do cliente COD_CLI relaciona com COD_CLI na

entidade CARROS em uma relação de

1:N

Inteiro, auto

numeração

NOME_CLI Nome do cliente Texto, 50

END_CLI Endereço do cliente Texto, 50

TEL_CLI Telefone do cliente Texto, 50

Modelo Relacional

O modelo relacional é um modelo de dados, adequado a ser o modelo de

um Sistema Gerenciador de Banco de Dados (SGBD), que se baseia no

princípio em que todos os dados estão guardados em tabelas (representação

bi-dimensional de dados composta de linhas e colunas).

Tornou-se um padrão de fato para aplicações comerciais, devido a sua

simplicidade e performance.

Para implementação do modelo relacional no SGBD utilizamos a linguagem

SQL, na qual cada entidade criada no DER se transformará em uma tabela; e

cada atributo em uma coluna da tabela.

Diagrama de

classes

Introdução

O diagrama de classe tem por objetivo descrever as informações que o

sistema deve representar e gerenciar.

Para elaborar um diagrama de classes, é preciso:

a) Identificar classes

b) Identificar atributos e associações

c) Especificar Hierarquias de Generalização/Especialização

Introdução

Classe: Uma classe é o agrupamento de objetos com a mesma estrutura de

dados (definida pelos atributos ou propriedades) e comportamento (operações),

ou seja, classe são as descrições dos objetos!

Após os levantamentos feitos na fase inicial, quando conhecemos os requisitos e

domínio do sistema, escrevemos o diagrama de classes.

Em programação, um diagrama de classes é uma representação da estrutura e

relações das classes que servem de modelo para objetos.

É o diagrama central da modelagem orientada a objetos

Diagrama de classe

Exemplo:

Diagrama de classe

Elementos de um diagrama de classes:

Classes

Generalização

Dependência

Relacionamentos:

Associação

Agregação

Composição

Representação dos elementos do

diagrama de classes

As classes na UML são representadas por

um retângulo divididos em três partes:

a) na primeira temos o nome da classe;

b) na segunda temos os atributos da

classe;

c) na terceira temos os métodos da

classe.

Representação dos elementos do

diagrama de classes

É comum adotar um padrão para nomear as classes.

Ex: todos os nomes de classes serão substantivos singulares com a

primeira letra maiúscula

Atributos

Os atributos são mostrados como um elemento textual no formato:

[visibilidade] nome do atributo: tipo

Utilizamos a seguinte notação para a visibilidade de atributos e métodos:

a) +: public

b) -: private

Métodos

Os métodos representam o conjunto de operações (comportamento) que a classe fornece.

Os métodos (ou operações) são mostrados na parte de baixo do retângulo como um elemento

textual no formato:

[visibilidade] nome da operação (lista de parâmetros): tipo de retorno

Associação

Uma associação é um

relacionamento estrutural

que indica que os objetos

de uma classe estão

vinculados a objetos de

outra classe.

Uma associação é

representada por uma

linha sólida conectando

duas classes.

Associação

Indicadores de multiplicidade:

a) 1 : Exatamente um

b) 1..* : Um ou mais

c) 0..* : Zero ou mais (muitos)

d) *: Zero ou mais (muitos)

e) 0..1 : Zero ou um

f) m..n: Faixa de valores (por exemplo: 4..7)

Associação

Exemplo:

a) Um estudante pode ser um aluno de uma disciplina e um jogador da

equipe de futebol

b) Cada disciplina deve ser cursada por no mínimo 1 aluno

c) Um aluno pode cursar de 0 até 8 disciplinas

Generalização

Uma generalização (herança) é mostrada com o símbolo ,como

mostrado nas imagens abaixo.

É um relacionamento entre itens gerais (superclasses) e itens mais

específicos (subclasses)

Dependência

Uma dependência é mostrada com uma linha (tracejada) com uma seta

entre dois elementos, como mostrado na relação entre Cliente e

Fornecedor.

Composição e agregação

A composição e a agregação são usadas para representar as relações de “todo” e

“parte” existentes entre alguns objetos.

Denominamos composição a relação na qual o objeto “todo” é constituído pelo

objeto “parte”, de maneira que sem o objeto “todo” o objeto “parte” não tem sentido.

A representação da composição contém um pequeno losango preenchido em um

dos lados da linha horizontal que liga os dois retângulos.

Representação dos elementos do

diagrama de classes

A instância Endereço só faz sentido se houver uma instância correspondente de

Cliente. Ou podemos perguntar: para que guardar um endereço se não sei a que

cliente ele pertence?

Quando excluímos o objeto “pai”, destruímos também o objeto “filho”. No nosso

exemplo, quando destruímos o objeto Cliente destruímos também o objeto Endereço.

Representação dos elementos do

diagrama de classes

A Agregação acontece quando usamos também um objeto “todo” e outro objeto “parte”; porém, a “vida” dos objetos é independente.

Neste caso, a representação gráfica possui o losango NÃO preenchido.

Se eliminarmos o objeto LinhaPedido, não devemos eliminar a DescriçãoProduto. Faz sentido não eliminarmos a DescriçãoProduto pois esse objeto provavelmente deverá ser utilizado por outros objetos.

Próxima aula...

Exemplos e exercícios de modelagem de casos de uso

Recommended