BASES DE DADOS I - di.ubi.pthugomcp/bd1/05_bd1_10_11.pdf · características de um sistema...

BASES DE DADOS I LTSI/2 Universidade da Beira Interior, Departamento de Informática Hugo Pedro Proença, 2010/2011

Modelo Conceptual

  Modelo Conceptual de uma Base de Dados

  Esquematização dos dados necessários para um conjunto de aplicações, visualizando simultaneamente o relacionamento existente entre eles. O modelo produzido auxiliará à criação da Base de Dados pretendida.

  Dois níveis (Duas fases):   Conceptual: Representação o mais aproximada possível da

realidade a modelar, sem considerar restrições técnicas ao nível da implementação.

  Físico: Adaptação do modelo conceptual construído anteriormente às características de um sistema informático específico.

Modelo Conceptual

  Existem normalmente duas abordagens para a concepção e modelação de uma base de dados:

  Bottom-Up

  Parte da identificação dos itens mais elementares de informação (atributos) e prossegue agrupando-os e identificando os relacionamentos entre eles. Esta é a metodologia mais comummente utilizada no processo de construção de bases de dados,sendo normalmente composta pelas seguintes fases:

  Modelo Entidade / Relacionamento   Análise das dependências funcionais   Construção do modelo

Modelo Conceptual

  Top-Down: Normalmente mais utilizada em grandes projectos, onde a quantidade e complexidade da informação a modelar é elevada. Começa pela identificação de grandes objectos de informação (entidades). Identifica os relacionamentos entre entidades e os atributos que compõem cada uma.

  Apresenta como principais vantagens:   Construção faseada   Facilita a comunicação entre o analista (autor do modelo) e o

implementador.   Não exige o levantamento antecipado de todos os itens de informação

(atributos) a incluir na base de dados.   Facilidade em lidar com grandes quantidades de informação.

Modelo Entidade / Relacionamento

  Entidade: Qualquer objecto ou conceito com interesse para a organização a respeito da qual é necessário registar informação. Esta deve poder ser identificada de forma unívoca.

  Exemplos:

Funcionário, Departamento, Produto, Peça, Contrato, ...

  Atributo: Toda a propriedade relativa a uma entidade pode ser classificada como um atributo. Devem ser elementos atómicos de informação.

  Relacionamento: Ligação lógica entre diferentes entidades.

Professor Disciplina Ensina

(Número, Nome, ...) (Código, Descrição, ...)

Diagrama de Ocorrências

  O Diagrama de Ocorrências serve para exemplificar um relacionamento entre entidades.

  Exemplo:

  ...Um professor pode leccionar várias disciplinas   ...Cada disciplina só é leccionada por um professor   ...Todas as disciplinas são leccionadas por algum professor

Professor P1 P2 P3 P4

Disciplina D1 D2 D3 D4

Diagrama Entidade / Relaccion.

  Relacionamento de grau 1:1 sem participação obrigatória de nenhuma das entidades. Cada instância de qualquer das entidades pode-se relacionar no máximo com uma instância da outra entidade.

A1

A2

A3

A4

B1

B2

B3

B4

1 1

A B


  Relacionamento de grau 1:1 com participação obrigatória de uma das entidades. No lado da entidade obrigatória todas as instâncias têm obrigatoriamente que se relacionar com uma instância da outra relação.

A1

A2

A3

A4

B1

B2

B3

1 1

A B


  Relacionamento de grau 1:1 com participação obrigatória de ambas as entidades. Qualquer instância tem obrigatoriamente que se relacionar com uma instância da outra relação

A1

A2

A3

B1

B2

B3 1 1

A B


  Relacionamento (A,B) de grau 1:N sem participação obrigatória. Cada instância de uma entidade (A) pode-se relacionar com “n” instâncias da outra (B). No entanto cada instância desta (B) apenas se relaciona, no máximo com uma entidade de (A).

A1

A2

A3

B1

B2

B3 1 n

A B

B4


  Relacionamento (A,B) de grau 1:N com participação obrigatória de (A). Cada instância de (A) pode-se relacionar com “n” instâncias de (B), tendo no mínimo que se relacionar com uma. Ao invés, cada instância de (B) apenas se relaciona, no máximo com uma entidade de (A).

A1

A2

B1

B2

B3 1 n

A B

B4


  Relacionamento (A,B) de grau 1:N com participação obrigatória de (B). Cada instância de (A) pode-se relacionar com “n” instâncias de (B), tendo no mínimo que se relacionar com uma. Ao invés, cada instância de (B) apenas se relaciona, no máximo com uma entidade de (A).

A1

A2

B1

B2

B3 1 n

A B

B4


  Relacionamento (A,B) de grau N:M sem participação obrigatória. Cada instância de (A) pode-se relacionar com “M” de (B). Cada instância de (B) pode-se relacionar com “N” de (A)

A1

A2

B1

B2

B3 n m

A B

B4 A3


  Relacionamento (A,B) de grau N:M com participação obrigatória de (A). Cada instância de (A) pode-se relacionar com “M” de (B), tendo no mínimo que se relacionar com uma. Cada instância de (B) pode-se relacionar com “N” de (A)

A1

A2

B1

B2

B3 n m

A B

B4 A3


  Relacionamento (A,B) de grau N:M com participação obrigatória de ambas as entidades. Cada instância de (A) pode-se relacionar com “M” de (B), tendo no mínimo que se relacionar com uma. Cada instância de (B) pode-se relacionar com “N” de (A) tendo igualmente que se relacionar com uma no mínimo.

A1

A2

B1

B2

B3 n m

A B

B4 A3


  Regra de Relacionamento: Modelação de relacionamentos binários de grau 1:1 e participação obrigatória de ambas as entidades:

  Apenas é necessária uma relação.

  A chave dessa relação pode ser a chave primária de qualquer das entidades.

1 1

Professor Disciplina

BI NomeProf CodDisciplina Descricao

123 Ana 5671 Álgebra

651 José 7182 Análise


  Regra de Relacionamento: Modelação de relacionamentos binários de grau 1:1 e participação obrigatória de apenas uma das entidades.

1 1


BI NomeProf CodDisciplina Descricao

123 Ana 5671 Álgebra

651 José 7182 Análise

null null 7612 Química

Surgirão valores “null” sempre que uma disciplina não tiver professor

São necessárias duas relações, uma para cada entidade. A chave primária da entidade com participação não obrigatória é usada como atributo na relação com participação obrigatória.

BI NomeProf CodDisciplina

123 Ana 5671

651 José 7182

CodDisciplina Descrição

5671 Álgebra

7182 Análise

7612 Química


  Regra de Relacionamento: Modelação de relacionamentos binários de grau 1:1 sem participação obrigatória nenhuma das entidades.

1 1


A criação de uma relação, ou a sua sub-divisão em duas, origina sempre o potencial aparecimento de valores nulos. Neste caso são necessárias 3 relações, uma para cada entidade e a terceira para modelar os relacionamentos entre elas.

BI NomeProf

123 Ana

651 José

898 Pedro


5671 Álgebra

7182 Análise

7612 Química

BI CodDisciplina

123 5671

651 7182


  Regra de Relacionamento: Modelação de relacionamentos binários de grau 1:N sem participação obrigatória nenhuma das entidades.

1 n


Neste caso são necessárias 3 relações, uma para cada entidade e a terceira para modelar os relacionamentos entre elas. A chave da tabela correspondente ao relacionamento será composta pela conjunto das chaves das duas entidades a modelar.

BI NomeProf

123 Ana

651 José

898 Pedro


5671 Álgebra

7182 Análise

7612 Química

9825 Física

BI CodDisciplina

123 5671

651 7182

123 7612


  Regra de Relacionamento: Modelação de relacionamentos binários de grau 1:N com participação obrigatória do lado (N)

1 n


Esta situação pode ser modelada eficientemente por duas relações, em que na relação do lado (N) se coloca como chave externa a chave primária da outra relação. A chave primária de cada relação corresponde à chave primária de cada entidade.

BI NomeProf

123 Ana

651 José

898 Pedro

CodDisciplina Descrição BI*

5671 Álgebra 123

7182 Análise 651

7612 Química 123

9825 Física 651


  Regra de Relacionamento: Modelação de relacionamentos binários de grau 1:N com participação obrigatória do lado (1)

1 n


Neste caso são necessárias três relações, uma para cada entidade e a terceira para modelar o relacionamento. A chave primária da tabela de relacionamento será a composição da chave primária das restantes entidades.

BI NomeProf

123 Ana

651 José

898 Pedro


5671 Álgebra

7182 Análise

7612 Química

9825 Física

5281 Biologia

BI CodDisciplina

123 5671

651 7182

123 7612

898 9825


  Regra de Relacionamento: Modelação de relacionamentos binários de grau M:N.

m n


Neste tipo de relacionamentos são sempre necessárias 3 tabelas. Uma para cada entidade e a terceira para modelar o relacionamento. Tal como nos casos anteriores, a chave primária desta relação será a composição das chaves das restantes entidades.

BI NomeProf

123 Ana

651 José

898 Pedro


5671 Álgebra

7182 Análise

7612 Química

9825 Física

5281 Biologia

BI CodDisciplina

123 5671

651 7182

123 7612

898 9825


  Regra de Relacionamento: Modelação de relacionamentos entre K entidades (K>2).

1 n


Neste tipo de relacionamentos são sempre necessárias no mínimo (K+1) tabelas. Uma para cada entidade e a ultima para modelar o relacionamento existente. Tal como nos casos anteriores, a chave primária da tabela relacionamento será a composição das chaves das restantes entidades.

Sala

m

Modelo Conceptual

  Processo de desenvolvimento de uma base de dados:

  Análise de requisitos.

  Fase inicial do processo de construção de uma base de dados. Corresponde à recepção de toda a informação e conjunto de regras que governarão o sistema pretendido. Constitui uma fase nuclear, uma vez que serve de fonte a todo o subsequente processo de desenvolvimento.

  Identificação de entidades.

  A partir da informação recebida na fase anterior, identificam-se e agrupam-se todos os itens de informação relevante.

Modelo Conceptual


  Identificação dos atributos próprios de cada entidade.   Este será o conjunto de atributos que pertencem exclusivamente a cada uma

das entidades identificadas no pontos anterior. Após esta fase, cada uma das entidades permanecerá isolada, não existindo atributos que denotam a existência de relações entre entidades.

  Identificação de relacionamentos entre entidades.   Após a identificação de cada entidade parte-se para a análise de

relacionamentos entre entidades. Quais as que se relacionam entre si ? De que forma será feita esse relacionamento?

Modelo Conceptual


  Análise da cardinalidade e obrigatoriedade das relações.   Para o conjunto de relacionamentos identificados anteriormente,

identificar o tipo, cardinalidade e obrigatoriedade de cada um. É um relacionamento binário ? Ternário ? Do tipo de “pertença”, “respeitante a”, ...? É obrigatório para alguma das relações ? Para todas ? Qual a cardinalidade da relação ?

  Construção de relações.   Após a fase anterior é possível esboçar o conjunto de relações e

respectivos atributos (próprios e de relacionamento) que irão compor a base de dados.

Modelo Conceptual


  Identificação de chaves candidatas e externas.   Tendo as relações definidas é necessário identificar claramente os

atributos ou conjuntos de atributos que podem ser usados como chaves primárias das relações (as chaves candidatas). Os atributos que denotam relacionamentos (chaves externas) devem também merecer atenção especial.

  Normalização do modelo.   Os passos anteriores permitiram a construção de um primeiro modelo do

sistema. É necessário proceder à sua optimização, executando o processo de normalização associado ao modelo relacional.

Modelo Conceptual


  Optimização do modelo.   A fase anterior (normalização) pode ter acrescentado regras ou

restarições ao sistema ? É importante garantir que as premissas originais permanecem satisfeitas. Finalmente pode-se partir para a optimização do modelo a implementar.   Alguma das chaves primárias identificadas tem demasiados atributos, ou

o tipo de algum atributo pode constituir problema ?   Será preferível implementar chaves numéricas sequenciais a algumas das

relações ? Quais ?

Modelo Conceptual


  É importante notar que o processo de construção descrito anteriormente é iterativo e normalmente regressivo, isto é, em cada momento pode ser necessária a passagem a fases anteriores, por forma a resolver problemas apenas identificados posteriormente.

  A análise de requisitos será em ultimo caso o ponto de partida de cada nova abordagem, e é de importãncia relevante a sua qualidade.

  Todas as regras estão claramente definidas?   Enuncia os obejectivos pretendidos para o sistema?   Existem ambiguidades?   É objectiva?

Modelo Conceptual

  Por vezes a análise de requisitos não fornece toda a informação necessária para a implementação da base de dados de suporte ao sistema de informação.

  Caso seja possível consultar as fontes de informação necessárias, será sempre esta a situação preferível, por forma a ajustar a base de dados o mais possível ao pretendido

  Caso contrário, cabe ao analista/implementador a terefa de fazer assumpções sobre o funcionamento do sistema, condicionando de alguma forma o seu desempenho.

Modelo Conceptual - Exemplo

  Uma empresa de distribuição de combustíveis decidiu implementar um sistema de fidelização de clientes através da atribuição de pontos por abastecimentos efectuados. O texto que se segue é um resumo resultante da análise de requisitos entretanto efectuada:

  “Temos neste momento 256 postos distribuídos pelo Continente e Regiões Autónomas e estamos firmemente decididos a alargar a nossa quota de mercado. Para isso pensámos em lançar uma nova promoção que visa essencialmente a atribuição de pontos aos clientes por cada litro de combustível abastecido. Cada cliente que deseje aderir basta efectuar o processo de registo num dos nossos postos e ser-lhe-à atribuído um cartão de acumulação de pontos. Estes poderão posteriormente ser trocados por um conjunto de prendas ou por litros de combustível. Sendo os combustíveis a nossa área de negócio, decidimos atribuir uma bonificação de 15% sobre a totalidade de pontos aos clientes que optem pela troca por combustível.

A inovação desta campanha reside no dinamismo da cotação de cada tipo de prenda. Consoante o desenrolar da promoção e analisando a relação entre os produtos mais desejados pelos clientes e a quantidade existente em stock, poderá ser alterada a quantidade de pontos necessários para a aquisição de um determinado produto, podendo esta cotação variar entre postos de abastecimento. Na tentativa de aumentar o consumo de combustível, decidimos atribuir um prazo de validade a cada ponto acumulado por cliente. Em principio, este será de 30 dias, apesar deste ponto ainda ser passível de alteração em reunião de direcção. Para evitar que os nossos clientes se sintam defraudados com a perca de pontos ou com a qualidade das prendas recebidas, decidimos permitir que prendas a partir de 2000 pontos possam ser atribuídas simultaneamente a mais que um cliente, isto é, permitir que vários clientes juntem os pontos necessários para receber prendas mais valiosas.

Modelo Conceptual - Exemplo

Outro dos aspectos importantes reside na facilidade com que o sistema permitirá a identificação de processos fraudulentos, bastantes comuns neste tipo de campanhas. (Enorme acumulação de pontos num determinado momento, acumulação de pontos simultaneamente em dois postos de abastecimentos distintos, etc...) Relativamente às prendas atribuídas, elas são todas adquiridas através da sede e posteriormente distribuídas pela nossa rede de abastecimento. Por esta razão o preço de custo é fixo para cada uma delas. O sistema que pretendemos servirá essencialmente para registar informação sobre os resultados desta campanha, os clientes que aderiram, as prendas atribuídas, litros abastecidos, etc... A nossa empresa dá grande relevância à área das novas tecnologias e estamos obviamente dispostos a aceitar sugestões que possam ter e permitam optimizar os resultados da campanha...”

Modelo Conceptual – Exemplo


 Construa um modelo conceptual de base de dados utilizando o modelo relacional.  Siga o processo de construção atrás

descrito para a construção de um modelo passível de implementação física.


  Passo 1: Análise de Requisitos

 Vulgarmente a análise de requisitos não é efectuada pela equipa que vai conceber e implementar a base de dados. Também neste caso, a análise (os aspectos mais importantes) é-nos fornecida através do texto anteriormente transcrito.

  Estão enunciadas todas as regras do sistema?   Podem-se inferir novas regras?  Necessário repetir processo de análise de requisitos para

esclarecimento de dúvidas, regras?


  Passo 2: Identificação de Entidades

  A partir da leitura (repetida) da análise de requisitos podem-se identificar as seguintes entidades:

•  Clientes

•  Postos de Abastecimento

•  Combustíveis •  Promoções

•  Pontos

•  Vendas

•  Prendas •  Fornecedores

•  Cartões


  Passo 3: Identificação dos atributos próprios de cada entidade.

  Qual a informação que é necessário guardar acerca de cada entidade identificada na fase anterior? Será que vale mesmo a pena considerar todas as entidades?

•  Clientes • NumCliente • Nome • Morada

•  PostosAbastecimento • CodPosto • Descrição • Localização • Encarregado



•  Pontos • ?

•  Vendas • DataVenda • Valor

Existe informação relevante para registar acerca de cada ponto ? Apesar de bastante referido na análise de requisitos, será necessária a criação de uma entidade ?



•  Promoções • CodPromoção • DataInicio • DataFim • Designação

•  Combustíveis • CodCombustivel • Descrição • ValorVenda

Para possibilitar que o sistema implementado funcione não só para esta, como outras promoções



•  Prendas • CodPrenda • Designação • ValorUnitário

•  Fornecedores • CodFornecedor • Nome • Morada

•  Cartões • CodCartão • DataRegisto


  Passo 4: Identificação dos relacionamentos entre entidades.  Quais os relacionamentos existentes entre as entidades

identificadas nos passos anteriores?   São obrigatórias?  Qual a sua cardinalidade?  O funcionamento do sistema pode ser flexibilizado sem

violação de nenhuma regra definida no processo de análise?

  É necessária a implementação do modelo entidade / relacionamento...


  Passo 4: Identificação dos relacionamentos entre entidades:

Cliente

PostoAbastecimento

Combustível

Promoção

Venda

Prenda Fornecedor

Registar

Referir

Localizar

Efectuar

Fornecimento

Respeitar

Oferta

Relativa

Cartão

Possuir


  Passo 5: Análise da cardinalidade e obrigatoriedade das relações:

  Para cada relação existente no modelo entidade/relacionamento é necessário expressar a sua cardinalidade e obrigatoriedade.

  Caso seja necessário, é altura de efectuar os diagramas de ocorrência para melhor ilustrar as regras subjacentes a cada relacionamento.

Exemplo:

Oferta1

Oferta2

Oferta3

Cartão1

Cartão2

Cartão3

Cartão4 Oferta4



 Que regras se podem inferir do diagrama de ocorrências anterior?

  Respeitam as restrições iniciais do problema?   Restringem/alargam a flexibilidade do sistema?

  Cada oferta é sempre efectuada a um único cartão?   Todas as ofertas são efectuadas a algum cartão?   Existem cartões que podem acumular ofertas?   Existem cartões sem nenhumas ofertas?



  A partir da análise dos diagramas de ocorrência, pode-se partir para um primeiro esboço da cardinalidade de cada relação.

  A obrigatoriedade de cada uma deve também estar explicita, uma vez que constitui um factor importante na transposição do modelo conceptual para o modelo físico da base de dados.

  A decomposição de relações de grau maior que dois deve também constituir uma preocupação, uma vez que irá facilitar a passagem para o modelo físico e a realização do processo de normalização.



Cliente

PostoAbastecimento

Combustível

Promoção

Venda

Prenda Fornecedor

Registar

Referir

Localizar

Efectuar

Fornecimento

Respeitar

Oferta

Relativa

Cartão

Possuir 1

1

n m

1

n

m n

n

n 1 n

n

n

1

p

1



Cliente

PostoAbastecimento

Combustível

Promoção

Venda

Prenda Fornecedor

Registar

Referir

Localizar

Efectuar

Fornecimento

Respeitar

Oferta

Relativa

Cartão

Possuir 1

1 m

1

n

1 n

n

1 n

n

n

1

1

1 Relativa

m



Cliente

PostoAbastecimento

Combustível

Promoção

Venda

Prenda Fornecedor

Registar

Referir

Localizar Efectuar

Fornecimento

Respeitar

Oferta

Relativa

Cartão

Possuir 1

1 m

1

n

1

1

n

n

n

1

1

1

Relativa

1

OfertaCartão

Relativa

1

n

n



Cliente

PostoAbastecimento

Combustível

Promoção

Venda

Prenda Fornecedor

Registar

Referir

Localizar Efectuar

Fornecimento

Respeitar

Oferta

Relativa

Cartão

Possuir 1

1 m

1

n

1

1

n

n

n

1

1

1

Relativa

OfertaCartão

Relativa

1

n

n

1 1


  Passo 6: Construção do esquema de relações

 Mediante a informação que é necessário registar e o diagrama entidade / relacionamento obtido na fase anterior, pode-se partir para um esboço do conjunto de relações (tabelas) existentes na base de dados.

 Aplicação das regras de transposição para o modelo físico.

  Análise da cardinalidade de cada relacionamento   Análise da obrigatoriedade de cada relacionamento.


  Passo 6: Construção do esquema de relações + Passo 7: Identificação das chaves primárias e externas de cada relação

Combustível • CodCombustível • Descrição • Preço

Venda • Data • Hora • CodCliente (*) • CodPostoAbastecimento (*) • CodCombustível (*) • Pontos

PostoAbastecimento • CodPostoAbastecimento • Descrição • Localização • Encarregado ?

Cliente • CodCliente • Nome • Morada

Fornecedor • CodFornecedor • Nome • Morada

? Cartão • CodCartão • CodCliente (*) • DataRegisto • CodPostoRegisto (*)


  Passo 6: Construção do esquema de relações + Passo 7: Identificação das chaves primárias e externas de cada relação

Oferta • CodOferta • Data • Hora • CodPrenda (*) • CodPromoção (*)

OfertaCliente • CodCliente (*) • CodOferta (*)

Promoção • CodPromoção • Descrição • DataInicio • DataFim

Prenda • CodPrenda • Nome • Pontos • CodFornecedor(*)

?


  Passo 6: Construção do esquema de relações + Passo 7: Identificação das chaves primárias e externas de cada relação   O primeiro modelo gerado levanta algumas duvidas, nomeadamente

relativamente a...   Determinar a cotação actual de cada prenda   Identificar qual o posto que atribuiu uma prenda (cada uma será

forçosamente atribuída num posto de combustível)   Registo do nome do encarregado (E se este se repetir em múltiplos postos)   Localização dos postos e morada dos clientes. Será de toda a utilidade a

disponibilização de informação detalhada (Sem redundância e sem violação de alguma forma normal inferior À terceira).

  Será necessário efectuar algumas alterações ao modelo...


Cliente

PostoAbastecimento

Combustível

Promoção

Venda

Prenda Fornecedor

Registar

Referir

Localizar Efectuar

Fornecimento

Respeitar

Oferta

Relativa

Cartão

Possuir 1

1 m

1

n

1 n

n

n

1

1

1

Relativa

OfertaCartão

Relativa

1

n

n

CodigoPostal

Localizar

Encarregado

Gerir Cotação

Referir

1

Efectuar n

n

1 1

1

n

1


  Passo 6 + Passo 7: Adição de relações e alteração das anteriores

CodigoPostal • Codigo • Cidade

Encarregado • CodEncarregado • Nome • Telefone

Cotação • CodPrenda • Data • Pontos

Oferta • CodOferta • Data • Hora • CodPrenda (*) • CodPostoCombustível(*)

PostoAbastecimento • CodPostoAbastecimento • Descrição • Localização • CodPostal(*) • CodEncarregado (*)

Cliente • CodCliente • Nome • Morada • CodPostal (*) • DataRegisto • CodPostoRegisto (*)

OfertaCartão • CodOferta (*) • CodCartão (*)


  Passo 8: Normalização do modelo

 Aplicar o processo de normalização a cada relação existente:  A 1FN é verificada?  A 2FN é verificada?  A 3FN é verificada?  A FNBC também?  Valerá a pena prosseguir com o processo até aos níveis

máximos (4FN e 5FN)? Existem dependências multi-valor ou de junção?

 Qual a forma normal escolhida? Porquê?


  Passo 9: Optimização do modelo

  Por motivos de eficiência ou segurança, será necessário substituir alguma chave primária identificada?

  No caso de chaves compostas pode-se chegar à conclusão de que é mais eficiente a utilização de chaves numéricas auto-incrementais.

  As chaves externas estão correctamente identificadas? São as ideais?   Após a execução deste processo, chega-se ao modelo proposto para

a resolução do problema.   Acrescentaram-se restrições ao funcionamento do sistema?   Não? (Caso ideal)   Sim? São razoáveis ?

  Poderá ser necessário consultar novamente a(s) pessoa(s) que pediu a base de dados.

BASES DE DADOS I - di.ubi.pthugomcp/bd1/05_bd1_10_11.pdf · características de um sistema...

Documents

Transcript of BASES DE DADOS I - di.ubi.pthugomcp/bd1/05_bd1_10_11.pdf · características de um sistema...