Docsity
Docsity

Prepare-se para as provas
Prepare-se para as provas

Estude fácil! Tem muito documento disponível na Docsity


Ganhe pontos para baixar
Ganhe pontos para baixar

Ganhe pontos ajudando outros esrudantes ou compre um plano Premium


Guias e Dicas
Guias e Dicas

Projeto - JEDI - Banco - de - Dados - Java - 219 - paginas, Manuais, Projetos, Pesquisas de Informática

Apostila de Banco de Dados do projeto JEDI

Tipologia: Manuais, Projetos, Pesquisas

2012

Compartilhado em 31/05/2012

augusto-nunes-7
augusto-nunes-7 🇧🇷

5

(1)

3 documentos

1 / 219

Toggle sidebar

Esta página não é visível na pré-visualização

Não perca as partes importantes!

bg1
Módulo 9
Banco de Dados
Lição 1
Introdução a Sistemas de Bancos de Dados
Versão 1.0 - Fev/2009
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28
pf29
pf2a
pf2b
pf2c
pf2d
pf2e
pf2f
pf30
pf31
pf32
pf33
pf34
pf35
pf36
pf37
pf38
pf39
pf3a
pf3b
pf3c
pf3d
pf3e
pf3f
pf40
pf41
pf42
pf43
pf44
pf45
pf46
pf47
pf48
pf49
pf4a
pf4b
pf4c
pf4d
pf4e
pf4f
pf50
pf51
pf52
pf53
pf54
pf55
pf56
pf57
pf58
pf59
pf5a
pf5b
pf5c
pf5d
pf5e
pf5f
pf60
pf61
pf62
pf63
pf64

Pré-visualização parcial do texto

Baixe Projeto - JEDI - Banco - de - Dados - Java - 219 - paginas e outras Manuais, Projetos, Pesquisas em PDF para Informática, somente na Docsity!

Módulo 9

Banco de Dados

Lição 1

Introdução a Sistemas de Bancos de Dados

Versão 1.0 - Fev/

Autor Ma. Rowena C. Solamo Equipe Rommel Feria Rick Hillegas John Paul Petines Necessidades para os Exercícios Sistemas Operacionais Suportados NetBeans IDE 5.5 para os seguintes sistemas operacionais:

  • Microsoft Windows XP Profissional SP2 ou superior
  • Mac OS X 10.4.5 ou superior
  • Red Hat Fedora Core 3
  • Solaris™ 10 Operating System (SPARC® e x86/x64 Platform Edition) NetBeans Enterprise Pack , poderá ser executado nas seguintes plataformas:
  • Microsoft Windows 2000 Profissional SP
  • Solaris™ 8 OS (SPARC e x86/x64 Platform Edition) e Solaris 9 OS (SPARC e x86/x64 Platform Edition)
  • Várias outras distribuições Linux Configuração Mínima de Hardware Nota: IDE NetBeans com resolução de tela em 1024x768 pixel Sistema Operacional Processador Memória HD Livre Microsoft Windows 500 MHz Intel Pentium III workstation ou equivalente 512 MB 850 MB Linux 500 MHz Intel Pentium III workstation ou equivalente 512 MB 450 MB Solaris OS (SPARC) UltraSPARC II 450 MHz 512 MB 450 MB Solaris OS (x86/x Platform Edition) AMD Opteron 100 Série 1.8 GHz 512 MB 450 MB Mac OS X PowerPC G4 512 MB 450 MB Configuração Recomendada de Hardware Sistema Operacional Processador Memória HD Livre Microsoft Windows 1.4 GHz Intel Pentium III workstation ou equivalente 1 GB 1 GB Linux 1.4 GHz Intel Pentium III workstation ou equivalente 1 GB 850 MB Solaris OS (SPARC) UltraSPARC IIIi 1 GHz 1 GB 850 MB Solaris OS (x86/x Platform Edition) AMD Opteron 100 Series 1.8 GHz 1 GB 850 MB Mac OS X PowerPC G5 1 GB 850 MB Requerimentos de Software NetBeans Enterprise Pack 5.5 executando sobre Java 2 Platform Standard Edition Development Kit 5.0 ou superior (JDK 5.0, versão 1.5.0_01 ou superior), contemplando a Java Runtime Environment, ferramentas de desenvolvimento para compilar, depurar, e executar aplicações escritas em linguagem Java. Sun Java System Application Server Platform Edition 9.
  • Para Solaris , Windows , e Linux , os arquivos da JDK podem ser obtidos para sua plataforma em http://java.sun.com/j2se/1.5.0/download.html
  • Para Mac OS X , Java 2 Plataform Standard Edition (J2SE) 5.0 Release 4, pode ser obtida diretamente da Apple's Developer Connection, no endereço: http://developer.apple.com/java (é necessário registrar o download da JDK). Para mais informações: http://www.netbeans.org/community/releases/60/relnotes.htm Java™ DB System Requirements Java™ DB is supported on the Solaris, Linux and Windows operating systems and Sun Java 1.4 or later.

1. Objetivos Nesta lição veremos uma introdução a sistemas de bancos de dados. A primeira parte descreve o ambiente de banco de dados utilizando o conceito de Gerenciamento de Recursos de Informações ou IRM ( Information Resource Management ) em que as empresas tem necessidade de gerenciar seus dados e informações. A segunda seção discute o processo de desenvolvimento de bases de dados utilizando o framework a Arquitetura de Sistema de Informação ou ISA ( Information System Architecture ). Isto ajudará a entender o lugar do banco de dados no processo de desenvolvimento e manutenção de sistemas de informação em uma empresa. Ao final desta lição, o estudante será capaz de: - Descrever o ambiente de banco de dados utilizando o conceito de Gerenciamento de Recursos de Informação - Descrever a Arquitetura de Sistemas de Informação como um framework para construção de sistemas de informação - Entender a importância do banco de dados dentro do desenvolvimento geral de sistemas de informação - Discutir os processos de análise, design e implementação de um banco de dados

2. Ambiente de Bases de Dados Com o passar dos anos, as empresas perceberam a importância do dado e da informação em suas operações diárias. IRM (Gerenciamento de Recursos de Informação) é o conceito de que a informação é um recurso corporativo muito importante e deve ser gerenciado utilizando alguns princípios básicos que são utilizados para gerenciar outros ativos da companhia como pessoal, equipamento e recursos financeiros. A seguir vemos os princípios básicos do qual IRM é derivado: 1. Empresas utilizam recursos que fluem em seu ambiente 2. Meio ambiente. Provê recursos retornando ele para seu ambiente de origem 3. Existem dois tipos básicos de recursos para serem gerenciados, especificamente: ● Recursos Físicos que são, por exemplo: pessoal, materiais, máquinas, entre outros ● Recursos Conceituais como dados e informações 4. Com o crescimento das operações organizacionais, torna-se difícil gerenciar os recursos físicos utilizando observações. Portanto, gerentes de negócios são forçados a depender de recursos conceituais 5. Os mesmos princípios básicos utilizados para o gerenciamento de recursos físicos podem ser utilizados para gerenciar os recursos conceituais 6. O gerenciamento de dados e informações, envolve: ● Aquisição de dados e informações antes que sejam necessárias ● Medidas de segurança para proteger recursos contra invasão, uso indevido e destruição ● Garantia de qualidade ● Procedimentos de liberação de recursos quando não são mais necessários à organização 7. Compromisso organizacional é necessário para gerenciar os dados e informações. Para implementar IRM, as seguintes funcionalidades são consideradas: 1. Gerenciamento de operações, tais como: agendamento, planejamento de capacidade, segurança de operações e desastres de recuperação de dados e informações 2. Garantia de qualidade para garantir que informações sejam fornecidas quando necessário 3. Gerenciamento de comunicações de LAN ou WAN 4. Gerenciamento de recursos de dados tais como análise de dados, design de bancos de dados, administração de dados e administração do banco de dados 5. Gerenciamento de projeto 6. Planejamento de Sistemas de Informação corporativos 7. Desenvolvimento e manutenção de sistemas Dados são fatos acerca de pessoas, objetos e eventos. Informação, por outro lado, é o dado que foi devidamente processado e apresentado num formulário para a interpretação humana, freqüentemente com o propósito de revelar tendências e padrões. Existem 5 tarefas envolvidas na conversão de dados em informações. São eles: 1. Aquisição 2. Armazenamento 3. Manipulação 4. Recuperação

3. Arquitetura de Sistemas de Informação (ISA) Para desenvolver sistemas de informação, um framework é utilizado para fornecer uma base para o planejamento estratégico, desenvolvimento e utilização de sistemas de informação que dão suporte a visão geral dos objetivos da organização. A arquitetura de sistemas de informação é um exemplo de framework. Representa um modelo conceitual ou plano que ilustra a estrutura dos sistemas de informação que são necessários para a organização. Fornece a base para planejamentos estratégicos e comunicações para a direção de toda a tecnologia da informação e o contexto principal para a tomada de decisão em uma área. A tabela 1 descreve este framework. Dado Processos Rede 1 Escopo do negócio Lista as entidades importantes de um negócio Lista as funções que o negócio deve realizar Lista de localidades em que o negócio opera 2 Modelo do negócio Entidade de negócio e seus inter-relacionamentos Decomposição de funções e processos Links de comunicação entre as localidades do negócio 3 Modelo do sistema de informação Modelo de negócios e seus inter-relacionamentos Fluxos entre os processos Distribuição em redes 4 Modelo de tecnologia Design do banco de dados Especificação dos processos Design de configuração 5 Definição da tecnologia Definição da estrutura e subestrutura do banco de dados Códigos do programa e blocos de código Definição de configuração (^6) Sistema de informação Dados e informações Aplicações Configuração do sistema Tabela 1 : Arquitetura de Sistemas de Informação Os três componentes principais neste framework são dados, processos e rede. Estes são as três colunas da tabela. 1. Dados consistem de entidades de dados e o relacionamento entre si. Representam o “o quê?” em um sistema de informação. Este é o componente com o qual bancos de dados são construídos. 2. Processos são seqüências de passos que convertem entradas em saídas (ou dados em informação). Representam o “como” em um sistema de informação. adfadfds adfadf asdfasdf asdfadf asdfa asdf adfadfds adfadf asdfasdf asdfadf asdfa asdf adfadfds adfadf asdfasdf asdfadf asdfa asdf adfadfds adfadf asdfasdf asdfadf asdfa asdf code code code code code code

  1. Rede descreve a localização onde os dados são armazenados, onde os processos são realizados bem como a conexão entre as localidades. Representam o “onde” em um sistema de informação. Cada linha representa uma camada arquitetural na construção de sistemas de informação de uma organização. Fornecem as 6 regras e perspectivas de cada camada.
  2. Escopo do Negócio – provê uma visão geral da estratégia dos sistemas de informação de uma organização. Define o escopo, missão e direção do negócio e quais sistemas de informação lhes dá suporte. Uma lista de entidades importantes, funções necessárias para que o sistema possa realizar aquilo que deve ser feito e identificar onde o negócio da empresa é realizado. Os proprietários do negócio são responsáveis por definir o escopo, missão e direção do negócio
  3. Modelo de Negócio – desenvolve os modelos que representam o escopo do negócio, missões e direções que o negócio irá tomar. Nesta camada, as entidades do negócio e seus inter-relacionamentos são definidos. A decomposição de funções e processos são identificadas. É definida as ligações entre as localidades de negócios. O arquiteto do sistema de informação é a pessoa que desenvolve estes modelos
  4. Modelo do Sistema de Informação – desenvolve o modelo da informação que dá suporte ao negócio da organização. Nesta camada, os dados e seus relacionamentos são modelados em detalhes. Os fluxos entre as aplicações também são processados e definidos. A distribuição pela rede também é identificada. O designer é responsável pelo desenvolvimento do modelo da informação
  5. Modelo de Tecnologia – converte o modelo do sistema de informação em um design que possa se adaptar às características e especificações da tecnologia. O projeto de um banco de dados, especificação de processos e configurações de rede são criados. O construtor desenvolve o design do sistema de informação
  6. Definição da Tecnologia – converte os modelos de tecnologia em declarações para gerar o sistema de informação. O projeto do banco de dados é traduzido em esquema e sub- esquemas do banco de dados. As especificações de processo são codificadas como códigos de programa e blocos de controle. Os projetos de configuração da rede são traduzidos em definição de configuração. O contratante traduz modelos de tecnologia em códigos
  7. Sistema de Informação – gerencia, utilize e opera o sistema de informação como um todo. Neste ponto, os usuários do sistema utilizam os dados e informações através de aplicativos especificados na configuração de sistema Para melhor utilizar este framework , duas regras simples são empregadas:
  8. Cada processo é mapeado para o dado que o utiliza. Ambos, dados e processos, são mapeados para as localizações na rede ou objetos onde serão distribuídos. Isto ajuda na garantia de que os vários componentes serão integrados aos demais
  9. A transformação de dados, processos e rede ocorrem simultaneamente de uma linha para a próxima. Esta regra evita inconsistência e retrabalho Este curso irá se concentrar no COMPONENTE DE DADOS do framework da Arquitetura do Sistema de Informação (ISA) na construção de um banco de dados. 4. Metodologia de Engenharia da Informação O framework ISA fornece um contexto de desenvolvimento e integração do sistema de informação. Sugere o tipo de processo no desenvolvimento de modelos em cada uma das camadas da arquitetura. Entretanto, não fornece uma forma para o desenvolvimento destes modelos. Portanto, uma organização deve utilizar uma ou mais metodologias e um conjunto de ferramentas de modelagem para desenvolver a representação arquitetural requisitada em cada perspectiva. Uma metodologia define o “como” ou conjunto de passos para se realizar determinado objetivo,

componentes da organização ● Localizações que mostrem os componentes organizacionais em mais de um único lugar ● Funções de negócio relacionados a grupos de processos de negócio que dão suporte a alguns aspectos da missão da empresa e que não são os mesmos da unidade organizacional ● Tipos de entidades

  1. Desenvolver os modelos da empresa utilizando as técnicas e ferramentas de modelagem a seguir: ● Técnica de decomposição funcional que consiste na quebra das funções de uma organização em busca de níveis de detalhes cada vez maiores, utilizando o Diagrama de Fluxo de Dados para modelar as funções ou processos ● Técnica de análise situacional que consiste no processo de análise e identificação de entidades que representam os dados importantes para a organização e o Diagrama de Entidade e Relacionamento utilizado para modelar a estrutura dos dados ● Matriz de planejamento para vincular as funções identificadas na decomposição funcional com às entidades com o propósito de identificar órfãos. Por exemplo, identifica quais funções não fazem uso de nenhuma entidade ou entidades que não são utilizadas por nenhuma função Figura 1 : Objetos de Planejamento Corporativo A fase de planejamento gera vínculos com a camada de Escopo do Negócio do framework ISA.

4.2. Fase de Análise

Esta fase é também conhecida como a fase da Engenharia de Requisitos. O propósito é desenvolver especificações detalhadas para o sistema de informação requisitado pela organização. Essas especificações incluem suporte a decisões e sistemas de informações executivos bem como sistemas de processamentos transacionais. Cobre o estudo da atual situação do negócio bem como a determinação dos requisitos para o novo sistema. Lida com uma área de negócios por vez que é o agrupamento de funções e entidades coesas que dão base para o desenvolvimento do sistema de informação. Critérios para a definição da Área de Negócios

  1. Área de negócios deve ser claramente delimitada.
  2. Pequena o bastante para ser bem entendida e facilmente gerenciável.
  3. Grande o suficiente para necessitar de bancos de dados compartilhados.

Lagyan Cards Incorporated

Business Goals:

  1. Increase distribution of cards by 50% for the next three years.
  2. Increase network of dealers nationwide by 10% for the next year.

Organizational Units:

  1. Sales Department
  2. Accounting Department
  3. Financial Department
  4. Business Centers

Business Functions:

  1. Inventory of e-Prepaid Cards
  2. Accounting of all financial transaction
  3. Sales monitoring of e-Prepaid Cards

List of Entity Types

  1. Customers, Direct Resellers, Dealers
  2. e-Prepaid cards, phone cards and internet access cards
  3. e-prepaid card transactions
  1. Não sobrepõe outras áreas do negócio. Dois modelos são desenvolvidos nesta fase. Particularmente, são o modelo conceitual e o modelo de processo. Passos para a Fase de Análise:
  2. Desenvolvimento do Modelo Conceitual O Modelo Conceitual é um modelo detalhado que captura as estruturas de dados utilizadas pela organização enquanto independentes de qualquer sistema gerenciador de banco de dados ou outra implementação. Inclui entidades relevantes, relacionamentos e atributos bem como regras de negócio e regras internas que definem como os dados são utilizados pela organização. O modelo conceitual utiliza o Diagrama Entidade-Relacionamento (DER) ou diagramas orientados a objetos para modelar os dados. Um exemplo de modelo conceitual é mostrado na seguinte figura: P H O N E C A R D T R A N S A C T I O N A C C O U N T P H O N E C A R D T Y P E T E L E C O M S E R V I C E P R O V I D E R I N T E R N E T S E R V I C E P R O V I D E R S E R V I C E P R O V I D E R h a s (^) u s e s p r o v i d e d b y h a s P H O N E C A R D Figura 2 : Modelo conceitual de transação de cartão telefônico
  3. Desenvolvimento do Modelo de Processos O Modelo de Processos fornece uma descrição lógica dos processos executados pelas funções da organização e os fluxos de dados entre os processos. Em um negócio, um processo é definido por um conjunto lógico de tarefas realizadas repetidamente para auxiliar em um ou mais funções do negócio. Transforma dados de entrada em dados de saída e tem limites definidos. Dois tipos básicos de processos existem em um negócio. Processos Físicos que convertem dados de entrada em dados de saída, e Processos de Informação que convertem dados em informação. Para identificar um processo em um negócio, a Técnica de Decomposição de Processos é utilizada. Consiste na identificação de processos pela decomposição de funções do negócio identificadas durante a fase de planejamento em seus componentes ou funções auxiliares. A ferramenta de modelagem utilizada para representar processos é o Diagrama de Fluxo de Dados (DFD). Este é um modelo gráfico para o fluxo de dados utilizados por um processo. Apresenta os agentes externos que fornecem ou recebem os dados, os processos que transformam os dados e o armazenamento de dados onde dados são coletados e mantidos. A fonte dos dados em um DFD corresponde aos nomes das entidades no DER. Um modelo de DFD é mostrado na seguinte figura:

fatores físicos. O objetivo principal de se ter o design físico do banco de dados é fornecer performance adequada para usuários de aplicações em termos de tempo de resposta, taxas de transferência, entre outros. Cópias de segurança e sua restauração são considerados no Projeto Físico. ACCOUNT CellPhoneNo PIN Balance Limit Status Type 09192345678 1234 $500,00 $2.500,00 ACT 2 09174561234 2345 $100,00 $2.000,00 ACT 2 09205467234 4523 $25.000,00 $300.000,00 ACT 1 09165647342 7812 $30.000,00 $300.000,00 ACT 1 STATUS CODE DESCRIPTION ACT Active Account BAR Barred Account TER Terminated Account TYPE CODE DESCRIPTION 1 Dealer Account 2 Direct Reseller PHONECARDTRANSACTION CELLPHONENO CARDNO LOADDATE RECIPIENT 09205467234 2346253782 DEC-24-2006 9223456173 09205467234 8736237634 DEC-24-2006 9178746345 Figura 4 : Exemplo de Projeto Lógico do Banco de Dados

  1. Desenvolvimento do Projeto de Processo. O propósito desse passo é especificar a lógica de cada um dos processos e incluir todas as referências para as entidades relevantes. Existem dois subpassos para o Projeto de Processo: ○ Especificar a lógica detalhada de cada processo ○ Desenhar interfaces de usuários que podem ser: menus, formulários e relatórios, entre outros A figura 5 é um exemplo da especificação de um Projeto de Processo. O trecho da especificação com fonte vermelha deve ser tratado como uma transação.

Figura 5 : Especificação do Projeto de Processo dos cartões telefônicos e-Prepaid

4.4. Fase de Implementação

O propósito da fase de implementação é construir e instalar o sistema de informação de acordo com os planos e designs. Isto envolve uma série de passos que acarretará a operacionalização do sistema de informação que incluem criar definições de banco de dados, criar códigos de programas, testar o sistema, desenvolver procedimentos operacionais e documentação. Project Name: e-Lagyan Distribution System Company: Lagyan Cards Incorporated Process Specifications: Phone Card Service Request INPUT: PAccountNo, PBalance, VFirstCellNo, VSecondCellNo, VService, VDenomination IF PBalance < VDenomination THEN MESSAGE "Insufficient Balance" Terminate Transaction ELSE SELECT InventoryCount INTO PCount FROM CellCardSupply WHERE Code IN (SELECT Code FROM CellCardType WHERE Denomination = VDenomination AND SPID = VService) IF (PCount < 0) THEN MESSAGE "No Card Available" TO VFirstCellNo ELSE SELECT FirstAvailableSerialNo, PIN, CardType INTO PSerialNo, PPIN, PCardType FROM CellCard WHERE CardType IN (SELECT Code FROM CellCardType WHERE SPID = VService AND Denomination = VDenomination) AND Status = "VALID" or "UNSOLD" IF VSecondCellNo <> NULL THEN INSERT INTO CellCardTrans VALUES (PAccountNo, PSerialNo, SYSDate, VSecondCellNo) ELSE INSERT INTO CellCardTrans VALUES (PAccountNo, PSerialNo, SYSDate, VFirstCellNo) ENDIF UPDATE Account SET Balance = Balance – Denomination WHERE AccountNo = PAccountNo UPDATE CellCardSupply SET Count = Count – 1 WHERE Code = PCardType UPDATE CellCard SET Status = 'Invalid' or 'Sold' WHERE SerialNo = PSerialNo IF VSecondCellNo <> NULL THEN SEND PPIN to VSecondCellNo ELSE SEND PPIN to VFirstCellNo ENDIF ENDIF ENDIF

● análises de performance e estatísticas de utilização ● facilidades para reorganização de índices e suas sobrecargas ● garbage collection e realocação para remover fisicamente os registros eliminados para consolidar o espaço liberado e realocá-lo quando houver necessidade

5.2. Arquitetura de Banco de Dados

Não é possível generalizar a estrutura de componentes de um SGBD, pois isto vária de sistema para sistema. No entanto, é útil entender o sistema de banco de dados visualizando seus componentes e como eles se relacionam. Figura 6^1 é uma arquitetura possível de SGBD. Um SGBD é modularizado em diversos componentes de softwares relacionados. Cada componente foi desenvolvido para executar operações específicas. O diagrama mostra como cada componente interage com os outros. A seguir listamos os componentes. ● Processador de Consultas. É considerado um dos principais componentes do SGBD. Transforma consultas em uma série de instruções de baixo-nível que são direcionadas ao software gerenciador do banco de dados ● Gerenciador de Banco de Dados. Interage com aplicações e consultas enviadas pelo usuário. Aceita consultas e examina esquemas externos e conceituais para determinar quais registros conceituais são requeridos para satisfazer uma consulta. Chama o gerenciador de arquivos para atender à requisição. Possui os seguintes componentes: ○ Controle de Autorização. Verifica se o usuário possui a autorização necessária para executar a operação requerida ○ Processador de Comandos. Responsável por controlar a operação quando se sabe que o usuário possui a autorização necessária ○ Validador de Integridade. Verifica se a operação requisitada satisfaz as restrições de integridade necessárias (como as restrições de chaves) ○ Otimizador de Consultas. Determina a estratégia para execução otimizada de consultas ○ Gerenciador de Transações. Executa o processamento das operações requeridas. Recebe as validações de integridade das transações ○ Agendador. Garante que operações concorrentes no banco de dados procedam sem conflitos entre si. Controla a ordem relativa em que as transações são executadas ○ Gerenciador de Recuperação. Garante que o banco de dados permaneça num estado consistente quando uma falha ocorrer (como violação de restrições). É responsável por confirmar ou abortar um transação ○ Gerente de Buffer. É responsável por transferir dados entre a memória principal e o disco ● Gerenciador de Arquivos. Manipula os arquivos internos de armazenamento e gerencia a alocação de espaço em disco. Não é responsável por gerenciar diretamente entradas e saídas de dados. Ao contrário, passa a requisição para o método de acesso apropriado ● Processador DML. Converte as instruções da Linguagem de Manipulação de Dados encontradas nas aplicações em chamadas de funções do banco de dados. Interage com o processador de consultas para gerar o código apropriado. ● Compilador DDL. Converte as instruções da Linguagem de Definição dos Dados em um conjunto de tabelas que contém os meta-dados. As tabelas são armazenadas no catálogo de sistema enquanto que informações de controle são armazenadas no cabeçalho dos arquivos de dados ● Gerenciador de Catálogo. Gerencia acesso e mantém os catálogos de sistema 1 Codd E. F. (1982) The 1981 ACM Turing Award Lecture: Relational Database: A Practical Foundation for Productivity. Comm. ACM, 25(2), 109-

Figura 6 : Arquitetura de Banco de Dados Database and System Catalog System Buffer Access Methods File Manager Buffer Manager Recovery Manager Transaction Manager Scheduler Command Processor Query Optimizer Integrity Checker Query Processor Catalog Manager Program Object Code Authorization Control

1. Objetivos O modelo de entidade-relacionamento é uma técnica de definição das necessidades de informação de uma organização. Provê alicerces para produtos de alta qualidade, adequando os sistemas às regras de negócio. Isto envolve identificar os objetos de importância para a organização ( entidades ), as propriedades desses objetos ( atributos ) e como eles se relacionam ( relacionamentos ). Seus dois objetivos principais são um modelo exato da necessidade de informação para a organização, que servirá como uma estrutura de desenvolvimento de novos sistemas, e prover um modelo independente de plataforma de armazenamento e formas de acesso, de modo que possam ser tomadas decisões técnicas de implementação e de coexistência com sistemas já desenvolvidos. Ao final desta lição, o estudante será capaz de: - Entender os conceitos básicos associados com o Modelo de Entidade-Relacionamento (MER) que descreve o modelo conceitual de alto nível o qual fornece suporte ao projeto do banco de dados - Aplicar a técnica de diagramação dos modelos de entidade-relacionamento para representar situações comuns de negócio

2. Modelo Entidade-Relacionamento O Modelo Entidade-Relacionamento é uma representação lógica detalhada dos dados de uma organização ou de uma área de negócio. É apresentado em termos de entidades no ambiente de negócio, seus relacionamentos e atributos. Este conceito foi introduzido por Chen em 1976.

2.1. Área de Atuação

Para organizar o modelo conceitual, utilizamos o conceito de Área Temática. Área Temática é uma área de interesse da empresa voltada para os recursos principais, produtos, atividades e sobre os quais devem ser mantidas informações. Isto pode ser feito pelo agrupando de entidades. Normalmente, usam-se substantivos plurais para representar uma Área Temática. Um exemplo de uma Área Temática é mostrado na seguinte figura: . Figura 1 : Exemplo de Área Temática Nesse exemplo, a Área Temática INVESTIMENTOS consiste de três entidades, nomeadas PROJETO, TAREFA e EQUIPE. Os propósitos de existirem Áreas Temáticas são prover estrutura necessária para ajudar a focar nas especificidades do negócio e definir o escopo do sistema.

2.2. Entidades

Entidades podem ser pessoas, lugares, objetos, eventos ou conceitos de ambiente do usuário aos quais a organização precisa manter dados. Seguem exemplo de entidades: Pessoa: EMPREGADO, ESTUDANTE, PACIENTE Lugar: ESTADO, REGIAO, PAIS Objeto: MAQUINA, PREDIO, AUTOMOVEL Tipos de Entidades são coleções de entidades que compartilham propriedades ou características em comum. Também são conhecidas como Classe de Entidade e também são representadas por uma caixa retangular com o nome da entidade no seu interior. O nome deve ser em letras maiúsculas e no singular. Figura 2 : Exemplos de Entidade s Uma instância de entidade , por outro lado, é uma ocorrência única de um tipo de entidade. Um exemplo é mostrado na seguinte figura: Tipo de Entidade: EMPREGADO Instâncias de EMPREGADO Atributos: NUMERO EMPREGADO 642-17- NOME Michelle Brady ENDERECO 100 Pacific ave. CIDADE San Francisco ESTADO Ca CEP 98713 ANO ADMISSAO 1989

INVESTIMENTOS

PROJETO

EQUIPE

TAREFAS

EMPREGADO CURSO CONTA