análise e projeto de sistemas - regilan€¦ · esse modelo é bastante popular e freqüentemente...
TRANSCRIPT
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