Administração e Projeto de banco de dados - Turma 3B€¦ · Web viewAdministração e Projeto de banco de dados. ... O modelo em redes surgiu como uma extensão ao modelo hierárquico,

Administração e Projeto de Banco de Dados

Administração e Projeto de banco de dados

2011Conceito de banco de dados. Modelagem conceitual de dados. Formas normais. Projeto lógico e físico, segundo o modelo relacional.

Sistemas de Informação e Processamento de dados

Página 1


Conteúdo1. Introdução e conceitos gerais_______________________________4

1.1 Banco de dados_________________________________________________________51.2 Sistema de Banco de Dados____________________________________________6

1.2.1 Principais componentes de um Sistema de Banco de Dados___________61.2.1.1 Dados______________________________________________________________61.2.1.2 Hardware___________________________________________________________71.2.1.3 Software____________________________________________________________71.2.1.4 Usuários____________________________________________________________71.2.1.4.1 Usuários finais:___________________________________________________81.2.1.5 Administrador de Banco de Dados (DBA)____________________________81.2.1.6 Projetista de Banco de Dados (Administrador de Dados)_____________81.2.1.7 Analistas de Sistemas e Programadores de Aplicações_______________81.2.2 Por que um Sistema de Banco de Dados?______________________________91.2.3 Vantagens tecnológicas da utilização de um Sistema de Banco de Dados 91.2.4 Quando não Utilizar um SGBD________________________________________101.2.5 Arquitetura de sistemas de banco de dados._________________________111.2.5.1 Os três níveis da arquitetura:______________________________________111.2.5.2 Independência de Dados___________________________________________12

1.3 Sistema de Gerenciamento de Bancos de Dados (SGBD)___________131.3.1 Funções do SGBD____________________________________________________131.3.2 Estrutura geral do SGBD_____________________________________________13

1.4 Linguagens para Manipulação de Dados_____________________________161.5 Modelos de Bancos de Dados___________________________________________171.5.1 O Modelo Hierárquico________________________________________________171.5.2 O modelo de Rede___________________________________________________181.5.3 O Modelo Relacional_________________________________________________201.5.4 O Modelo Orientado a Objetos________________________________________21

2. Modelagem de Dados_______________________________________222.1 Modelo Conceitual de Dados (MCD)_____________________________________222.1.1 Modelo Lógico de Dados (MLD)_______________________________________232.1.2 Modelo Físico de Dados (MFD)________________________________________23

2.2 Modelo E-R_____________________________________________________________232.2.1 Entidade_____________________________________________________________252.2.2 Atributo______________________________________________________________262.2.3 Descritivo:___________________________________________________________262.2.4 Identificador:________________________________________________________262.2.5 Composto:___________________________________________________________262.2.6 Derivado:____________________________________________________________262.2.7 Multivalorado:_______________________________________________________262.2.8 Relacionamento_____________________________________________________272.2.9 Grau do Relacionamento ou Cardinalidade___________________________282.2.9.1 Relacionamento Um-para-Um (1:1)________________________________282.2.9.2 Relacionamento Um-para-Muitos (1:N)_____________________________29

Página 2


2.2.9.3 Relacionamento Muitos-para-Muitos (N:N)__________________________302.3 Participação____________________________________________________________312.4 Relacionamentos Reflexivos (auto-relacionamento)_____________________33

2.5 Extensões do Modelo Entidade x Relacionamento__________________332.5.1 Relacionamentos entre Múltiplas Entidades__________________________332.5.1.1 Entidade associativa_______________________________________________342.5.1.2 Agregação_________________________________________________________352.5.1.3 Generalização (Supertipos) e Especialização (Subtipos)____________362.5.1.3.1 Generalização___________________________________________________362.5.1.3.2 Especialização___________________________________________________372.5.1.3.3 Generalização X Especialização__________________________________37

3. Bancos de Dados Relacionais______________________________383.1 Definição_______________________________________________________________383.2 Tabela Relacional______________________________________________________393.3 O conceito de Chave no Modelo Relacional__________________________40

3.3.1 Chave Primária (Primary Key)________________________________________403.3.2 Chave Estrangeira (Foreign Key)_____________________________________423.3.3 Chave Candidata_____________________________________________________433.3.4 Chave Secundária (Secundary Key)__________________________________43

3.4 Regras de Integridade do Modelo Relacional________________________433.4.1 Integridade de Identidade____________________________________________433.4.2 Integridade Referencial______________________________________________43

3.5 Características do Modelo Relacional________________________________44

4. Derivação do Modelo Entidade x Relacionamento para o Modelo Lógico Relacional________________________________________44

4.1 Regras de Conversão__________________________________________________444.2 Mapeamento de Entidades_____________________________________________444.3 Mapeando atributos____________________________________________________444.4 Relacionamento 1:N (envolvendo entidades distintas)__________________444.5 Relacionamento 1:N (envolvendo auto-relacionamento)________________454.6 Relacionamento 1:1____________________________________________________454.7 Relacionamento N:N___________________________________________________474.8 Relacionamento Múltiplo_______________________________________________474.9 Generalizações_________________________________________________________47

5. Normalização de Dados_____________________________________495.1 Definição_______________________________________________________________49

5.2 Primeira Forma Normal (1FN)___________________________________________505.3 Segunda Forma Normal (2FN) - Dependências Funcionais_______________515.4 - Terceira Forma Normal (3FN) - Dependências Transitivas______________515.5 Quarta Forma Normal (4FN)____________________________________________535.6 Quinta Forma Normal (5FN)____________________________________________54Bibliografia___________________________________________________________________57

Página 3


1. Introdução e conceitos gerais

Igualmente a muitas tecnologias na computação industrial, os fundamentos de bancos de dados relacionais surgiram na empresa IBM, nas décadas de 1960 e 1970, através de pesquisas de funções de automação de escritório. Foi durante um período da história na qual empresas descobriram que estava muito custoso empregar um número grande de pessoas para fazer trabalhos como armazenar e indexar (organizar) arquivos. Por este motivo, valia a pena os esforços e investimentos em pesquisar um meio mais barato e ter uma solução mecânica eficiente.

Muitas pesquisas foram conduzidas durante este período, cujos modelo hierárquicos, de rede e relacionais e outros modelos foram descobertos, bem como muita tecnologia utilizada hoje em dia.

Em 1970 um pesquisador da IBM - Ted Codd - publicou o primeiro artigo sobre bancos de dados relacionais. Este artigo tratava sobre o uso de cálculo e álgebra relacional para permitir que usuários não técnicos armazenassem e recuperassem grande quantidade de informações. Codd visionava um sistema onde o usuário seria capaz de acessar as informações através de comandos em inglês, onde as informações estariam armazenadas em tabelas.

Devido à natureza técnica deste artigo e a relativa complicação matemática, o significado e proposição do artigo não foram prontamente realizados. Entretanto ele levou a IBM a montar um grupo de pesquisa conhecido como System R (Sistema R).

O projeto do Sistema R era criar um sistema de banco de dados relacional o qual eventualmente se tornaria um produto. Os primeiros protótipos foram utilizados por muitas organizações, tais como MIT Sloan School of Management (uma escola renomada de negócios norte-americana). Novas versões foram testadas com empresas aviação para rastreamento do manufaturamento de estoque.

Eventualmente o Sistema R evoluiu para SQL/DS, o qual posteriormente tornou-se o DB2. A linguagem criada pelo grupo do Sistema R foi aStructured Query Language (SQL) - Linguagem de Consulta Estruturada). Esta linguagem tornou-se um padrão na indústria para bancos de dados relacionais e hoje em dia é um padrão ISO (International Organization for Standardization). A ISO é a Organização Internacional de Padronização. A linguagem SQL era originalmente conhecida como SEQUEL (Structured English QUEry Language) e depois foi abreviada como SQL.

Os primeiros do mercado

Mesmo a IBM sendo a companhia que inventou o conceito original e o padrão SQL, eles não produziram o primeiro sistema comercial de banco de dados. O feito foi realizado pela Honeywell Information Systems Inc., cujo sistema foi lançado em junho de 1976. O sistema era baseado em muitos princípios do sistema que a IBM concebeu, mas foi modelado e implementado fora da IBM.

O primeiro sistema de banco de dados construído baseado nos padrões SQL começaram a aparecer no início dos anos 80 com a empresa Oracle através do Oracle 2 e depois com a IBM através do SQL/DS, servindo como sistema e repositório de informações de outras empresas.

Página 4


Estes sistemas somente nasceram a partir da insistência de um jornal técnico em utilizar BNF para SQL e este jornal publicou tal artigou. BNF é o conjunto de sintaxes de linguagem de computador que explica exatamente como cada comando interage com os outros comandos e o que pode ou não ser realizado, como os comandos são formados em assim por diante. Por causa da publicação deste artigo, empresas puderam utilizá-lo para modelar seus próprios sistemas, os quais seriam 100% compatíveis com o sistema da IBM.

Dado, Informação e Conhecimento

Dado é qualquer elemento identificado em sua forma bruta que, por si só, não conduz a uma compreensão de determinado fato ou situação (Oliveira, 2005)

Informação é o dado trabalhado que agrupado de maneira lógica permite aos usuários desta informação tomar decisões. (Oliveira, 2005)

Conhecimento é a informação associada em múltiplos contextos. Segundo Laudon e Laudon 1999, conhecimento é o conjunto de ferramentas conceituais e categorias usadas pelos seres humanos para criar, colecionar, armazenar e compartilhar a informação.

Figura 1 Relação entre dado, informação e conhecimento.

1.1 Banco de dadosUm “banco de dados” pode ser definido como um conjunto de “dados” devidamente relacionados. Por “dados” podemos compreender como “fatos conhecidos” que podem ser armazenados e que possuem um significado implícito. Porém, o significado do termo “banco de dados” é mais restrito que simplesmente a definição dada acima. Um banco de dados possui as seguintes propriedades:

um banco de dados é uma coleção lógica coerente de dados com um significado inerente; uma disposição desordenada dos dados não pode ser referenciada como um banco de dados;

um banco de dados é projetado, construído e preenchido com dados para um propósito específico; um banco de dados possui um conjunto pré definido de usuários e aplicações;

Página 5


um banco de dados representa algum aspecto do mundo real, o qual é chamado de “mini-mundo” ; qualquer alteração efetuada no mini-mundo é automaticamente refletida no banco de dados.

Um banco de dados pode ser criado e mantido por um conjunto de aplicações desenvolvidas especialmente para esta tarefa ou por um “Sistema Gerenciador de Banco de Dados” (SGBD). Um SGBD permite aos usuários criarem e manipularem bancos de dados de propósito gerais. O conjunto formado por um banco de dados mais as aplicações que manipulam o mesmo é chamado de “Sistema de Banco de Dados”.

1.2 Sistema de Banco de DadosSegundo C. J. Date um sistema de banco de dados é basicamente um sistema computadorizado de manutenção de registros. O banco de dados, por si só, pode ser considerado como o equivalente eletrônico de um armário de arquivamento, ou seja, ele é um repositório ou recipiente para uma coleção de arquivos de dados computadorizados, de modo geral a finalidade de um banco de dados é armazenar informações e permitir que os usuários busquem e atualizem essas informações quando forem requisitadas. As informações em questão podem ser qualquer coisa que tenha um significado ao individuo ou à organização a que o sistema deve servir. Os usuários de um sistema podem realizar (ou melhor, solicitar que o sistema realize) diversas operações envolvendo tais arquivos, como por exemplo:

Acrescentar novos arquivos ao banco de dados Inserir dados em arquivos existentes Buscar dados de arquivos existentes Alterar dados de arquivos existentes Excluir dados de arquivos existentes Remover arquivos existentes do banco de dados

1.2.1 Principais componentes de um Sistema de Banco de DadosUm sistema de banco de dados envolve 4 componentes principais:

Dados Hardware Software Usuários

1.2.1.1 DadosÉ comum em um banco de dados referir-se aos dados como dados “persistentes”, ou seja, podemos sugerir intuitivamente que esses dados ficam armazenados no banco de dados e só podem ser removidos por uma requisição explícita ao mesmo. Isso difere de outros tipos de dados, como, por exemplo, dados de entrada, dados de saída, filas de trabalho, instruções SQL e quaisquer outros que possuam natureza transitória.

Os dados em um sistema de banco de dados são integrados e compartilhados

Por integrado, queremos dizer que o banco de dados pode ser considerado como uma unificação de vários arquivos que, de outro modo, seriam distintos, com a eliminação de qualquer redundância parcial ou total entre esses arquivos.

Página 6


Por compartilhado, queremos dizer que o banco de dados pode ser compartilhado entre diferentes usuários, no sentido de que diferentes usuários podem ter acesso aos mesmos dados, possivelmente ao mesmo tempo (acesso concorrente).

Também devemos fazer uma diferenciação entre dado e informação. O dado é aquilo que realmente é armazenado no banco de dados, enquanto a informação refere-se ao significado desses dados para determinado usuário. Por exemplo, se armazenamos no banco de dados a data de nascimento de um cliente como sendo 10/01/1970, esse dado nos da a informação que em 20/12/1990 esse cliente estava com 20 anos.

1.2.1.2 HardwareOs componentes de hardware do sistema de banco de dados consistem em:

Volumes de armazenamento secundário – normalmente discos magnéticos -, que são usados para manter os dados armazenados, juntamente com os dispositivos de E/S (entrada/saída) associados (unidades de disco etc), controladores de dispositivos, canais de E/S e assim por diante.

Processador(es) de hardware e memória principal associada, que são usados para dar suporte à execução do software do sistema de banco de dados.

1.2.1.3 SoftwareEntre o banco de dados físico – ou seja, os dados fisicamente armazenados – e os usuários do sistema existe uma camada de software conhecida como gerenciador de banco de dados, ou mais freqüentemente conhecido SGBD – Sistema Gerenciador de Banco de dados. O SGBD será responsável por tratar todas as requisições citadas anteriormente como acrescentar novos arquivos ao banco de dados ou inserir dados em arquivos existentes etc..

1.2.1.4 UsuáriosOs usuários (finais) acessam o banco de dados interativamente através de alguma aplicação ou interface on-line que na maioria das vezes podem ser oferecidas pelo fornecedor do SGBD estas aplicações são internas (built-in), e não escrita pelos usuários, a maior parte dos sistemas possui pelo menos uma aplicação built-in, chamada de processador de linguagem de consulta, por meio do qual o usuário pode emitir requisições ao banco de dados.

Consideremos de forma geral quatro classes de usuários que interagem com o banco de dados:

1.2.1.4.1 Usuários finais: Existem basicamente três categorias de usuários finais que são os usuários finais do banco de dados, fazendo consultas, atualizações e gerando documentos:

Usuários casuais: acessam o banco de dados casualmente, mas que podem necessitar de diferentes informações a cada acesso; utilizam sofisticadas linguagens de consulta para especificar suas necessidades;

Página 7


Usuários novatos ou paramétricos: utilizam porções pré-definidas do banco de dados, utilizando consultas pré-estabelecidas que foram exaustivamente testadas;

Usuários sofisticados ou de alto nível: são usuários que estão familiarizados com o banco de dados e realizam consultas complexas (query).

1.2.1.5 Administrador de Banco de Dados (DBA)Em um ambiente de banco de dados, o recurso primário é o banco de dados por si só e o recurso secundário o SGBD e os softwares relacionados. A administração destes recursos cabe ao Administrador de Banco de Dados, o qual é responsável pela autorização de acesso ao banco de dados e pela coordenação e monitoração de seu uso.

São tarefas do DBA:

Definição da estrutura de armazenamento e a estratégia (ou método) de acesso.

Concessão de autorização para acesso a dados. Definição de controles de integridade. Definição de estratégias para cópia de segurança e recuperação. Monitoramento do desempenho. Execução de rotinas de desempenho. Modificação da organização física.

1.2.1.6 Projetista de Banco de Dados (Administrador de Dados)O Projetista de Banco de Dados é responsável pela identificação dos dados que devem ser armazenados no banco de dados, escolhendo a estrutura correta para representar e armazenar dados. Muitas vezes, os projetistas de banco de dados atuam como “staff” do DBA, assumindo outras responsabilidades após a construção do banco de dados. É função do projetista também avaliar as necessidades de cada grupo de usuários para definir as visões que serão necessárias, integrando-as, fazendo com que o banco de dados seja capaz de atender a todas as necessidades dos usuários.

São tarefas do AD: Definição e atualização do esquema do banco de dados.

1.2.1.7 Analistas de Sistemas e Programadores de Aplicações Os analistas determinam os requisitos dos usuários finais e desenvolvem especificações para transações que atendam estes requisitos, e os programadores são os responsáveis pelo desenvolvimento de aplicações em linguagens como Java, Cobol, C#, C++, VB.net e etc. que fazem chamadas ou requisições ao SGBD através de instruções SQL

Página 8


1.2.2 Por que um Sistema de Banco de Dados?As vantagens de um sistema de banco de dados em relação aos métodos tradicionais, baseados em papel são muitas, como por exemplo:

Densidade: Não há a necessidade de arquivos de papel, possivelmente volumosos.

Velocidade: A máquina pode obter e atualizar dados com uma velocidade muito maior do que o ser humano.

Atualidade: Informações precisas e atualizadas estão disponíveis a qualquer momento sob consulta.

Proteção: Os dados podem ser bem protegidos contra a perda não intencional e acesso ilegal.

1.2.3 Vantagens tecnológicas da utilização de um Sistema de Banco de Dados

Controle de Redundância

A redundância consiste no armazenamento de uma mesma informação em locais diferentes, provocando inconsistências. Em um Banco de Dados as informações só se encontram armazenadas em um único local, não existindo duplicação descontrolada dos dados.

Compartilhamento de Dados

Um banco de dados multiusuário deve permitir que múltiplos usuários acessem o banco de dados ao mesmo tempo. Este fator é essencial para que múltiplas aplicações integradas possam acessar o banco.

O banco de dados multiusuário deve manter o controle de concorrência para assegurar que o resultado de atualizações seja correto. Um banco de dados multiusuário deve fornecer recursos para a construção de múltiplas visões.

Restrição a Acesso não Autorizado

O banco de dados deve dispor de recursos que possibilitem selecionar a autoridade de cada usuário. Assim um usuário poderá realizar qualquer tipo de acesso, outros poderão ler alguns dados e atualizar outros e outros ainda poderão somente acessar um conjunto restrito de dados para escrita e leitura.

Tolerância a Falhas

Um banco de dados deve fornecer recursos para recuperação de falhas tanto de software quanto de hardware.

Integridade

Um banco de dados deverá impedir que aplicações ou acessos pelas interfaces possam comprometer a integridade dos dados.

Suporte a transações

Página 9


Uma transação é uma unidade lógica de trabalho (mais precisamente, uma unidade lógica de trabalho de banco de dados), em geral envolvendo diversas operações de banco de dados, onde uma operação só pode ser validada pelo banco de dados se todas as demais operações da transação também o forem.

Exemplo: Transação bancária de transferência de dinheiro. A transação só pode ser validada se as operações de débito em uma conta origem e crédito em uma conta destino forem validados.

1.2.4 Quando não Utilizar um SGBDEm algumas situações, o uso de um SGBD pode representar uma carga desnecessária aos custos quando comparado à abordagem processamento tradicional de arquivos como, por exemplo:

Generalidade que um SGBD fornece na definição e processamento de dados;

Sobrecarga na provisão de controle de segurança, controle de concorrência, recuperação e integração de funções.

Problemas adicionais podem surgir caso os projetistas de banco de dados ou os administradores de banco de dados não elaborem os projetos corretamente ou se as aplicações não são implementadas de forma apropriada. Se o DBA não administrar o banco de dados de forma apropriada, tanto a segurança quanto a integridade dos sistemas podem ser comprometidas. A sobrecarga causada pelo uso de um SGBD e a má administração justificam a utilização da abordagem processamento tradicional de arquivos em casos como:

O banco de dados e as aplicações são simples, bem definidas e não se espera mudanças no projeto;

A necessidade de processamento em tempo real de certas aplicações, que são terrivelmente prejudicadas pela sobrecarga causada pelo uso de um SGBD;

Não haverá múltiplo acesso ao banco de dados.

Página 10


1.2.5 Arquitetura de sistemas de banco de dados.A arquitetura ANSI/SPARC (American National Standards Institute / Standards Planning And Requirements Committee) ou “Tree-Schemas” é uma proposta do Study Group on Data Base Management Systems para representar os sistemas de banco de dados. A meta desta arquitetura é separar as aplicações de usuários da base de dados física. Nessa arquitetura a base de dados pode ser definida em três níveis: Nível Externo, Nível Conceitual e Nível Interno ou Físico.

1.2.5.1 Os três níveis da arquitetura: O nível externo ou visão (também conhecido como nível lógico de

usuário) é o mais próximo dos usuários, ou seja, é aquele que se ocupa de como os dados são vistos por usuários individuais, como os dados estão organizados para formar a informação para cada usuário. O nível externo possui esquemas externos ou visões e não depende do sistema gerenciador de banco de dados. Cada esquema descreve a visão da informação de um grupo de usuários. Cada visão descreve, tipicamente, à parte da base de dados que um particular grupo de usuários está interessado e esconde o resto da base de dados do mesmo.

O nível conceitual (também conhecido como nível lógico de comunidade, ou as vezes apenas como nível lógico, sem qualificação) possuí um esquema conceitual que representa a estrutura da base de dados que é o produto da normalização. È uma visão mais apropriada para os projetistas onde todos os conjuntos de dados do nível externo estão quebrados em pedaços lógicos, fundidos para reduzir repetição, e estruturados para eliminar dependências. O esquema conceitual é uma descrição global da base de dados, que omite detalhes da estrutura de armazenamento físico e se concentra na descrição de entidades, tipos de dados, relacionamento e restrições (Diagrama de Entidade e Relacionamento).

O nível Interno ou Físico (também conhecido como nível de armazenamento) é o mais próximo do meio de armazenamento físico, ou seja, é aquele que se ocupa do modo como os dados, ou melhor, registros e arquivos são fisicamente armazenados dentro da base de dados e depende fortemente do SGBD selecionado. É uma visão mais apropriada aos programadores de base de dados. Todos os conjuntos de dados do nível físico estão organizados para aperfeiçoar a velocidade de execução, maximizar a disponibilidade dos dados, e manter os dados seguros.

Página 11


Figura 2 Os três níveis da arquitetura.

Analisando a imagem podemos observar que o nível externo se preocupa com as percepções dos usuários individuais, enquanto o nível conceitual está preocupado com uma percepção da comunidade de usuários. Na maioria dos casos alguns usuários não terão acesso a toda informação do banco de dados, mas somente acessarão algumas partes das informações contidas no mesmo; assim, haverá muitas “visões externas” distintas, cada qual consistindo em uma representação abstrata de alguma parte da informação contida no banco de dados, e haverá uma “visão conceitual”, consistindo em uma representação igualmente abstrata do banco de dados em sua totalidade. Do mesmo modo haverá uma “visão interna”, representando o modo como os dados estão armazenados internamente.

1.2.5.2 Independência de DadosA “independência de dados” pode ser definida como a capacidade de se alterar um esquema em um nível em um banco de dados sem ter que alterar um nível superior (figura anterior). Existem dois tipos de independência de dados:

Independência de dados lógica: é a capacidade de alterar o esquema conceitual sem ter que alterar o esquema externo ou as aplicações do usuário, ou seja, podemos alterar o esquema conceitual sem a necessidade de reescrever os programas aplicativos. Algumas vezes é necessário alterar a estrutura lógica do banco de dados como por exemplo adicionando alguma nova entidade (tabela) ao banco.

Independência de dados física: é a capacidade de alterar o esquema interno sem ter que alterar o esquema conceitual, o esquema externo ou as aplicações do usuário, ou seja, podemos alterar o esquema físico sem a necessidade de reescrever os programas aplicativos. Algumas vezes

Página 12


são necessárias modificações no nível físico para melhorar o desempenho.

1.3 Sistema de Gerenciamento de Bancos de Dados (SGBD)

Um sistema gerenciador de banco de dados (SGBD) é responsável por armazenar dados de forma confiável e permitir fácil recuperação e atualização desses dados. Um SGBD relacional (SGBDR ou RDBMS relational database management system) armazena dados de forma relacional, isto é na forma de linhas e colunas.

A seqüência abaixo ilustra o papel do sistema de gerência de banco de dados, de forma conceitual:

1. O usuário emite uma solicitação de acesso.2. O SGBD intercepta a solicitação e a analisa.3. O SGBD inspeciona os esquemas externos (ou sub-esquemas)

relacionados àquele usuário, os mapeamentos entre os três níveis, e a definição da estrutura de armazenamento.

4. O SGBD realiza as operações solicitadas no banco de dados armazenado.

Exemplos de SGBD: Oracle, Microsoft SQL Server. IBM DB2, SyBase, Paradox, Progress, MySql, Microsoft Access etc.

1.3.1 Funções do SGBD Interação com o sistema de arquivos do sistema operacional. Cumprimento da integridade. Cumprimento da segurança. Cópias de segurança (“backup”) e recuperação. Controle de concorrência. Otimização e execução dos comandos DML. Dicionário de Dados. Desempenho.

1.3.2 Estrutura geral do SGBD

Um sistema de banco de dados é dividido em módulos que tratam de cada uma das responsabilidades do sistema geral. Na maioria dos casos, o sistema operacional do computador fornece apenas os serviços mais básicos e o sistema de banco de dados precisa ser construído sobre essa base. Portanto, o projeto do sistema de banco de dados precisa incluir considerações sobre a interface entre o sistema de banco de dados e o sistema operacional.

Os componentes funcionais de um sistema de banco de dados incluem:

Gerenciador de arquivos, que gerencia a alocação do espaço na armazenagem do disco e as estruturas de dados usadas para representar a informação armazenada no disco.

Gerenciador do banco de dados, que fornece a interface entre os dados de baixo nível armazenados no disco e os programas aplicativos e de consulta submetidos ao sistema.

Processador de consultas, que traduz os comandos numa linguagem de consulta para instruções de baixo nível que o gerenciador do banco de

Página 13


dados pode interpretar. Além disso, o processador de consultas tenta transformar uma requisição do usuário em uma forma compatível e mais eficiente com respeito ao banco de dados, encontrando uma boa estratégia para executar a consulta.

Pré-compilador da DML, que converte comandos da DML embutidos em um aplicativo para chamadas de procedimento normal na linguagem hospedeira. O pré-compilador precisa interagir com o processador de consultas pra gerar o código apropriado.

Compilador da DDL, que converte comandos da DDL em um conjunto de tabelas contendo metadados ou "dados sobre dados".

Adicionalmente, diversas estruturas de dados são requeridas como parte da implementação do sistema físico, incluindo:

Arquivos de dados, que armazenam o banco de dados propriamente dito.

Dicionário de dados, que armazena metadados sobre a estrutura do banco de dados. O dicionário de dados é usado com freqüência. Assim, deve-se dar grande ênfase no desenvolvimento de um bom projeto e implementação eficiente do dicionário.

Índices, que fornecem acesso rápido aos itens de dados guardando determinados valores.

Estrutura básica de um sistema gerenciador de Banco de dados

Figura 3 Estrutura básica de um SGBD

Página 14


Visão expandida da arquitetura do sistema de banco de dados

Figura 4 Estrutura expandida de um SGBD

Página 15


1.4 Linguagens para Manipulação de DadosQuando tratamos de banco de dados, e desejamos criar uma estrutura lógica para armazenamento e organização destes dados e realizar consultas, alterações, restrições de acesso, definições de esquemas e etc, fazemos uso de uma linguagem que nos auxilie e facilite realizar esta tarefa.

As Linguagens para Manipulação de Dados são divididas em três grupos de comandos: DDL (Data Definition Language - Linguagem de Definição de Dados)

Para a criação dos objetos do banco de dados (tabelas, índices, relacionamentos, visões etc) utilizamos a linguagem DDL (Data Definition Language - Linguagem de Definição de Dados). O SGBD possui um compilador DDL que permite a execução das declarações para identificar as descrições dos esquemas e para armazená-las no catálogo do SGBD.

DML (Data Manipulation Language - Linguagem de Manipulação de Dados)

Uma vez que o banco de dados esteja criado, usa-se uma linguagem para fazer a manipulação dos dados (ler, inserir, alterar e excluir), a DML (Data Manipulation Language - Linguagem de Manipulação de Dados).

DCL (Data Control Language)

Linguagem de Controle de Dados – Utilizada para tratar as permissões do banco de dados como a concessão (GRANT) ou revogação (REVOKE) de privilégios no banco de dados.

Página 16


1.5 Modelos de Bancos de DadosExistem diversos modelos de banco de dados, e cada modelo tem suas características de manipulação e armazenamento dos dados, dentre estes modelos vamos conhecer os quatro principais e mais comuns modelos encontrados no mercado, são eles: o modelo hierárquico, em rede, relacional e orientado a objetos.

Para explicarmos cada modelo, iremos utilizar as informações da tabela abaixo:

Nome Município Estado Conta SaldoJoão SBC SP A102 400,00Ana SP SP A101 500,00

A202 900,00Pedro Osasco SP A305 350,00

1.5.1 O Modelo HierárquicoO modelo hierárquico foi o primeiro a ser reconhecido como um modelo de dados. Seu desenvolvimento somente foi possível devido à consolidação dos discos de armazenamento endereçáveis, pois esses discos possibilitaram a exploração de sua estrutura de endereçamento físico para viabilizar a representação hierárquica das informações. Nesse modelo de dados, os dados são estruturados em hierarquias ou árvores. Os nós das hierarquias contêm ocorrências de registros, onde cada registro é uma coleção de campos (atributos), cada um contendo apenas uma informação. O registro da hierarquia que precede a outros é o registro-pai, os outros são chamados de registros-filhos. Um registro é, em muitos aspectos, similar a uma entidade do modelo entidade x relacionamento que veremos mais a frente. Cada registro é uma coleção de campos (atributos), cada qual contendo somente um valor. Uma ligação é uma associação entre dois registros. O relacionamento entre um registro-pai e vários registros-filhos possui cardinalidade 1:N. Os dados organizados segundo este modelo podem ser acessados segundo uma seqüência hierárquica com uma navegação do topo para as folhas e da esquerda para a direita. Um registro pode estar associado a vários registros diferentes, desde que seja replicado. A replicação possui duas grandes desvantagens: pode causar inconsistência de dados quando houver atualização e o desperdício de espaço é inevitável. O sistema comercial mais divulgado no modelo hierárquico foi o Information Management System da IBM Corp(IMS). Grande parte das restrições e consistências de dados estava contida dentro dos programas escritos para as aplicações. Era necessário escrever programas na ordem para acessar o banco de dados

A representação gráfica deste modelo se realiza mediante a criação de uma árvore invertida, os diferentes níveis ficam unidos mediante relações.

Página 17


Figura 5 Banco de Dados Modelo Hierárquico

Neste modelo só se podem representar relações 1:M (uma para muitos), por isso apresenta vários inconvenientes como:

Não se admitem relações N:M (muitos para muitos) Um segmento filho não pode ter mais de um pai.

Não se permitem mais de uma relação entre dois segmentos.

Para acessar a qualquer segmento é necessário começar pelo segmento raiz

A árvore se deve percorrer na ordem designada.

Exemplos de banco de dados Hierárquico: IBM’s IMS (DL/1, IMS DB, IMS DC), SYSTEM 2000

1.5.2 O modelo de RedeO modelo em redes surgiu como uma extensão ao modelo hierárquico, eliminando o conceito de hierarquia e permitindo que um mesmo registro estivesse envolvido em várias associações. No modelo em rede, os registros são organizados em grafos onde aparece um único tipo de associação (set) que define uma relação 1:N entre 2 tipos de registros: proprietário e membro. Desta maneira, dados dois relacionamentos 1:N entre os registros A e D e entre os registros C e D é possível construir um relacionamento M:N entre A e D. O gerenciador Data Base Task Group (DBTG) da CODASYL (Committee on Data Systems and Languages) estabeleceu uma norma para este modelo de banco de dados, com linguagem própria para definição e manipulação de dados. Os dados tinham uma forma limitada de independência física. A única garantia era que o sistema deveria recuperar os dados para as aplicações como se eles estivessem armazenados na maneira indicada nos esquemas. Os geradores de relatórios da CODASYL também definiram sintaxes para dois aspectos chaves dos sistemas gerenciadores de dados: concorrência e segurança. O mecanismo de segurança fornecia uma facilidade na qual parte do banco de dados (ou área) pudesse ser bloqueada para prevenir acessos simultâneos, quando necessário. A sintaxe da segurança permitia que uma senha fosse associada a cada objeto descrito no esquema. Ao contrário do Modelo Hierárquico, em que qualquer acesso aos dados passa pela raiz, o modelo em rede possibilita acesso a qualquer nó da rede sem passar pela raiz. No Modelo em Rede o sistema comercial mais divulgado é o CAIDMS da Computer Associates. Nesta estrutura qualquer componente pode se relacionar com qualquer outro. Diferentemente do modelo hierárquico, neste modelo, um filho pode ter vários pais.

Página 18


Figura 6 Banco de Dados Modelo de Rede

Os conceitos básicos no modelo em rede são: O tipo de registro, que representa um nó. Elemento, que é um campo de dados.

Agregado de dados, que define um conjunto de dados com nome.

Este modelo de dados permite representar relações N:M (muitos para muitos)

Exemplo de banco de dados de Rede: IDMS (Cullinet), DMS 1100 (Sperry), TOTAL (Cincom Systems)

Página 19


1.5.3 O Modelo RelacionalO Modelo Relacional de banco de dados é o modelo no qual iremos nos aprofundar nesse curso, por ser um modelo de fácil entendimento e o mais utilizado atualmente. Ele representa os dados por meio de conceitos matemáticos da teoria dos conjuntos. Dirigido, este modelo foi proposto pelo pesquisador Edgar Ted Frank Codd em jun/1970, este modelo melhora a visão dos dados, a abordagem relacional faz com que o banco de dados seja representado como um conjunto de tabelas bidimensionais, originadas em linhas e colunas. A relação entre duas tabelas é feita através de colunas em comum (chave primária e chave estrangeira). O modelo relacional não tem caminhos pré-definidos para se fazer acesso aos dados como nos modelos que o precederam. O modelo relacional implementa estruturas de dados organizadas em relações. Porém, para trabalhar com essas tabelas, algumas restrições precisaram ser impostas para evitar aspectos indesejáveis, como: Repetição de informação, incapacidade de representar parte da informação e perda de informação. Essas restrições são: integridade referencial, chaves e integridade de junções de relações.

Figura 7 Banco de Dados Relacional

Algumas de suas principais características são: Pode ser entendido e usado por qualquer usuário. Permite ampliar o esquema conceitual sem modificar as aplicações de

gerenciamento.

Os usuários não necessitam saber onde se encontram os dados fisicamente.

O elemento principal deste modelo é a relação que se representa mediante uma tabela.

Exemplo de banco de dados Relacional: Oracle, DB2(IBM), MySql (MySql AB), Firebird (Open Source), PostgreSQL (Open Source), SQL Server (Microsoft),Sybase Adaptative Server (Sybase)

Página 20


1.5.4 O Modelo Orientado a ObjetosOs bancos de dados orientados a objeto começaram a se tornar comercialmente viáveis em meados de 1980. A motivação para seu surgimento está em função dos limites de armazenamento e representação semântica impostas no modelo relacional. Alguns exemplos são os sistemas de informações geográficas (SIG), os sistemas CAD e CAM, que são mais facilmente construídos usando tipos complexos de dados. A habilidade para criar os tipos de dados necessários é uma característica das linguagens de programação orientadas a objetos.Contudo, estes sistemas necessitam guardar representações das estruturas de dados que utilizam no armazenamento permanente. A estrutura padrão para os bancos de dados orientados a objetos foi feita pelo Object Database Management Group (ODMG), basicamente um sistema em que a unidade de armazenamento é o objeto, com o mesmo conceito das linguagens de programação orientadas a objetos. A diferença fundamental é a persistência dos objetos, ou seja, os objetos continuam a existir mesmo após o encerramento do programa. Através das construções orientadas a objeto, os programadores podem esconder os detalhes da implementação de seus módulos, compartilhar a referência a objetos e expandir seus sistemas através de módulos existentes. Hoje, porém, acredita-se que os Bancos de Dados Orientados a Objetos serãousados em aplicações especializadas, enquanto os sistemas relacionais continuarão a sustentar os negócios tradicionais, onde as estruturas de dados baseadas em relações são suficientes. O diagrama de classes UML serve geralmente como o esquema para o modelo de dados orientado a objetos.

Figura 8 Banco de Dados Orientado a Objetos

Algumas de suas principais características são:

Os dados são armazenados como objetos Os objetos são organizados numa hierarquia de tipos, e subtipos que

recebem as características de seus supertipos. O acesso aos dados pode ser rápido porque as junções geralmente não

são necessárias.

Exemplo de banco de dados OO: CACHÉ, VERSANT, DB4Objects, O2, GEMSTONE, JASMINE, MATISSE, Objectivity/DB, Ozone.

Página 21


2. Modelagem de Dados

Para começarmos a tratar de modelagem de dados, vamos primeiramente definir modelo.

Modelo: é a representação abstrata e simplificada de um sistema real, com a qual se pode explicar ou testar o seu comportamento, em seu todo ou em partes.

“Temos que modelar o mundo observado, seja ele real ou imaginário. Paulo Cougo”

O processo de modelagem de um banco de dados é dividido em três etapas:

Modelo Conceitual Modelo Lógico Modelo Físico

2.1 Modelo Conceitual de Dados (MCD)O Modelo Conceitual representa e/ou descreve a realidade do ambiente observado, constituindo-se em uma visão global dos principais dados e relacionamentos (estruturas de informação), independente das restrições de implementação impostas por tecnologias, técnicas de implementação ou dispositivos físicos, ou seja, na etapa de elaboração do modelo conceitual, pouco importa se o sistema escolhido será um SGBD Relacional, de Rede ou Hierárquico.

Quando se fala em Modelo Conceitual, estamos nos referindo a primeira etapa do projeto de um sistema de aplicação em banco de dados, ele deve ser utilizado para o nível de conversação, entendimento, transmissão, validação de conceitos, mapeamento do ambiente etc...

O objetivo do Modelo Conceitual é descrever as informações contidas em uma realidade, as quais irão estar armazenadas em um banco de dados. É uma descrição em alto nível (macro-definição), mas que tem a preocupação de captar e retratar toda a realidade de uma organização, setor, repartição, departamento, negócio etc.

Como dizemos no inicio deste tópico, o Modelo Conceitual não retrata os aspectos ligados à abordagem do banco de dados que será utilizado e tão pouco se preocupa com as formas de acesso ou estruturas físicas implementadas por um SGBD (Sistema Gerenciador de Banco de Dados) específico.

O resultado de um Modelo Conceitual é um esquema que representa a realidade das informações existentes, assim como as estruturas de dados que representam estas informações.

2.1.1 Modelo Lógico de Dados (MLD)Defini-se como modelo lógico de dados aquele em que os objetos, suas características e relacionamentos têm a representação de acordo com as regras de implementação e limitantes impostos por algum tipo de tecnologia.

Página 22


O Modelo Lógico tem o seu início a partir do Modelo Conceitual, levando em consideração a abordagem de rede, hierárquica, relacional ou orientada a objeto, esse modelo deve ser elaborado respeitando-se e implementando-se conceitos tais como chaves de acesso, controles de chaves duplicadas, normalização, ponteiros, headers, integridade referencial, entre outros. Estas são preocupações e necessidades somente relevantes ao Modelo Lógico, jamais devem ser levadas ao Modelo conceitual.

O Modelo Lógico descreve as estruturas que estarão contidas no banco de dados, de acordo com as possibilidades permitidas pela abordagem, mas sem considerar, ainda, nenhuma característica específica de um Sistema Gerenciador de Banco de Dados (SGBD), resultando em um esquema lógico de dados sob a ótica de uma das abordagens citadas.

2.1.2 Modelo Físico de Dados (MFD)O Modelo Físico irá partir do Modelo Lógico e descreve as estruturas físicas de armazenamento de dados, tais como: tamanho de campos, índices, tipo de preenchimento destes campos, nomenclaturas, etc. Será projetado de acordo com os requisitos de processamento e uso mais econômico dos recursos computacionais. Este modelo detalha o estudo dos métodos de acesso ao SGBD, para elaboração dos índices de cada informação colocada nos Modelos Conceituais e Lógicos.

Cada empresa fornecedora do SGBD poderá definir um diferente modo de implementação física das características e recursos necessários para o armazenamento e manipulação das estruturas de dados

Esta é a etapa final do projeto de Banco de Dados, na qual será utilizada a Linguagem de Definição de Dados do SGBD (DDL), para a criação física do banco de dados proposto.

2.2 Modelo E-RA abordagem Entidade-Relacionamento

Em março de 1976, Peter P. Chen publicou um trabalho intitulado “The Entity-Relationship Model: Toward the unified view of data”, no qual definia uma possível abordagem para o processo de modelagem dos dados. Esse trabalho, após sua divulgação e ampla aceitação, passou a ser considerado como um referencial definitivo para o processo de modelagem de dados. A abordagem entidade-relacionamento é composta de uma técnica de diagramação e de um conjunto de conceitos que devem ser entendidos e respeitados. O modelo entidade-relacionamento é um modelo de dados conceitual de alto nível, cujos conceitos foram projetados para estar o mais próximo possível da visão que o usuário tem dos dados, não se preocupando em representar como estes dados estarão realmente armazenados. O modelo ER é utilizado principalmente durante o processo de projeto de banco de dados.

O modelo ER utiliza, basicamente, os retângulos para representar as entidades, losangos para representar os relacionamentos, elipses (balões) para indicar e alocar os atributos, linhas que unem os atributos aos conjuntos de entidades e os conjuntos de entidades aos relacionamentos, elipses duplas que representam os relacionamentos multivalorados e linhas duplas que

Página 23


indicam participação total de uma entidade em um conjunto de relacionamentos.

O diagrama ER fornece uma visão lógica do banco de dados, fornecendo um conceito mais generalizado de como estão estruturados os dados de um sistema.

Os objetos que compõem o diagrama ER estão listados a seguir, na figura abaixo:

Página 24


Os principais conceitos utilizados para a construção do modelo ER são:

Entidade Atributo Relacionamento Cardinalidade

2.2.1 EntidadeDefini-se entidade como aquele objeto que existe no mundo real com uma identificação distinta e um significado próprio, ou seja, é todo objeto concreto ou abstrato que tem existência própria, quando considerado o âmbito de um negócio. São coisas sobre as quais desejamos arquivar informações. São as “coisas” que existem no negócio, ou ainda, descrevem o negócio em si.

A entidade é representada por um retângulo, conforme as figuras abaixo:

Em um universo observado, estaremos reconhecendo objetos (coisas). Estes objetos estarão sendo percebidos como elementos individualizados, mas, ao mesmo tempo, poderão ser enquadrados em um conjunto ou categoria em função de suas semelhanças, estes objetos neste processo de observação serão as entidades, vejamos um exemplo:

ExemploAo observarmos um ambiente de produção de uma fábrica, nos defrontaremos com:

Maquinas de produção de peças. Funcionários operadores dessas máquinas. Conjunto de ferramentas para operar e dar manutenção as máquinas. Procedimentos de operações a serem realizadas. Procedimentos de medições e verificação da qualidade das peças

produzidas. Máquinas recuperadoras de peças. Funcionários responsáveis pela verificação da qualidade das peças. Peças produzidas nos mais diversos formatos.

Dentre esses elementos observados, poderemos perceber a existência de vários conjuntos distintos de elementos (entidades), entre eles:

Máquina – que representa todas as máquinas observadas. Funcionário – que representa todos os funcionários. Ferramenta – que representa todas as ferramentas. Peças – que representará todos os tipos de peças produzidas.

Página 25

Cliente Fornecedor Pedido Aluno


2.2.2 AtributoÉ uma informação que caracteriza uma entidade ou um relacionamento. Toda entidade possui atributos, mas nem todo relacionamento é caracterizado por atributos. Os atributos podem ser classificados em: Descritivo, Identificador, Composto, Derivado e Multivalorado.

2.2.3 Descritivo:É utilizado para descrever a entidade.

2.2.4 Identificador:É utilizado para identificar unicamente uma linha da entidade.

2.2.5 Composto:É um conjunto de tributos simples que pode ser referido como um único atributo.

2.2.6 Derivado:Pode ter um valor que é derivável de valores de outros atributos.

2.2.7 Multivalorado:Pode ser preenchido com muitos valores.

Página 26

AtributoDescritivo

AtributoIdentificador

AtributoComposto

Agregado

agregado

Agregado

AtributoDerivado

Nome-atributo

AtributoMultivalorado


Exemplo de uma entidade e seus diferentes tipos de atributos:

2.2.8 RelacionamentoÉ a ligação entre duas ou mais entidades. Ao observarmos os objetos e reconhecê-los, estaremos quase que imediatamente, reconhecendo as relações existentes entre eles. Muitas vezes a própria observação de um relacionamento será o ponto de partida para a identificação dos objetos que dele participam. O que estabelecerá associações válidas ou não será simplesmente o grau de fidelidade e completeza que consigamos atingir durante o processo de modelagem.

O relacionamento é representado por um losango.

Exemplo:

Assim, se desejarmos ter, conceitualmente, representado um ambiente observado onde “Anderson é proprietário de um jipe amarelo”, podemos segui a seguinte estratégia:

1. Identificar os objetos envolvidos (entidades):

Pessoa (Anderson)

Carro (Jipe Amarelo)

2. Caracterizar os objetos (atributos):

Pessoa (nome, data nascimento, número CPF e etc.)

Carro (marca, cor, ano de fabricação, modelo etc.)

3. Representar os objetos:

4. Identificar o relacionamento entre os objetos:

Relacionamento: Pessoa é proprietária de Carro

Página 27

Rua

Número

Bairro

Cidade

Endereço

Idade

AlunoData Nasc. RA

Data Nasc.Telefones

Aluno DisciplinaFreqüenta

Pessoa Carro


5. Representar o relacionamento

2.2.9 Grau do Relacionamento ou CardinalidadeQuando temos um relacionamento entre duas entidades, o número de ocorrências de uma entidade que está associado a ocorrências de outra entidade determina o Grau do Relacionamento ou Cardinalidade deste fato.

Quando questionamos se um homem poderia estar casado com mais de uma mulher, estamos na realidade questionando o grau de relacionamento que existe entre as entidades Homem e Mulher.

Em modelagem, ao se tratar de relacionamentos, podemos apresentar os mesmos através de três possibilidades:

Um-para-Um (1:1)

Um-para-Muitos (1:N)

Muitos-para-Muitos (N:N) ou (M:N)

É o grau de ligação entre as entidades. É representada por “0”, “1” ou “N”, significando “zero”, “um” ou “muitos” respectivamente.

Forma de leitura

Entidade – Relacionamento – Cardinalidade – Entidade. A leitura deve ser feita em ambas as direções.

2.2.9.1 Relacionamento Um-para-Um (1:1)

Pois um Marido só é casado com uma Esposa, e, também, uma esposa só estará casada com um Marido.

Cardinalidade Mínima e Máxima

Um Curso é coordenado por no mínimo 1 e no máximo 1 coordenador.

Um coordenador coordena no mínimo 1 e no máximo 1 curso.

Página 28

1,11,1Curso CoordenadorCoorden

a

mínimo

máximo

Pessoa CarroÉ Proprietári

a

Marido EsposaCasado

1 1


2.2.9.2 Relacionamento Um-para-Muitos (1:N)

Pois uma empresa pode vir a ter 0 (nenhuma), 1 (uma), ou N (diversas) filiais em sua estrutura operacional, mas desde que essa filial seja de uma dada empresa não poderá ser de nenhuma outra.


Um vendedor atende zero ou uma região.

Uma região é atendida por zero ou muitos vendedores.

Página 29

0,10,NVendedor RegiãoAtend

e

PD

Têxtil

Eletrônica

Douglas

Pedro

Ana

Campinas

Piracicaba

Sorocaba

Mário

Carla

João

Ana

Empresa FilialPossui1 N


2.2.9.3 Relacionamento Muitos-para-Muitos (N:N)

Pois certo livro pode ser escrito pó um conjunto de autores (3, por exemplo), e, por sua vez, cada um dos autores pode escrever mais de um livro.


Um fornecedor fornece zero ou muitos produtos.

Um produto é fornecido por zero ou muitos fornecedores.

Página 30

W

X

Y

Z

A

B

C

D

E

0.N0.NFornecedor Produto

Fornece

Livro AutorEscrit

o

N N


2.3 ParticipaçãoOutra restrição muito importante é a participação. A participação define a existência de uma entidade através do relacionamento, podendo ser parcial ou total. Veja um exemplo.

A participação do empregado é parcial, pois nem todo empregado gerencia um departamento, porém a participação do departamento neste relacionamento é total, pois todo departamento precisa ser gerenciado por um empregado. Desta forma, todas as entidades do tipo DEPARTAMENTO precisam participar do relacionamento, mas nem todas as entidade do tipo entidade EMPREGADO precisam participar do relacionamento.

Estas restrições são chamadas de restrições estruturais.

Página 31

RH

Projetos

Compras

LuizPaulaPedroMoacirFernandaMariaJosé

EMPREGADO Gerencia

DEPARTAMENTO

Empregado DepartamentoGerencia


2.3.1 Considerações sobre Entidades Fortes e Entidades Fracas

Alguns autores adotam, para fins de caracterização de uma entidade, um critério que as classifica em fortes (regulares) ou fracas. Onde uma entidade fraca é uma entidade cuja existência depende de alguma outra entidade, no sentido de que ela, não poder existir se essa outra entidade também não existir.

Esta caracterização se dá através da analise de existência de duas condições básicas:

Dependência de existência.

Se uma entidade B depender de uma entidade A para existir, teremos em B uma entidade fraca, enquanto que A, se não depender de ninguém para existir, será considerada uma entidade forte.

Dependência de identificador.

Se uma entidade não possui atributos suficientes para formar uma chave primária, este tipo de entidade é considerado uma entidade fraca. Do ponto de vista de modelagem conceitual, assim como a dependência de existência este tipo de critério pode ser visto como dispensável, pois sua importância será reconhecida sob o ponto de vista de projeto lógico, onde as chaves identificadoras, utilizadas como diferenciadores entre instâncias dos elementos, ou como método de endereçamento de registro, passam a ter papel vital durante a o processo de estrutura de dados.

A relação entre um entidade forte e uma fraca deve ser 1:N.

Por exemplo, em um modelo de cadastro de funcionários, poderíamos ter a entidade “Empregado” e para este empregado uma entidade “Dependente”, os dependentes de um empregado, poderiam ser classificados como entidades fracas, pois os dependentes não poderiam existir sem um empregado não fosse cadastrado. Em particular se algum empregado for excluído, todos os seus dependentes também devem ser excluídos.

Um conjunto de entidades fracas é identificado no modelo E-R pela linha dupla usada no retângulo e no losango do relacionamento correspondente. No diagrama abaixo, o conjunto de entidades fracas pagamento é dependente do conjunto de entidades fortes Empréstimo pelo conjunto de relacionamento pagamento_empréstimo. A figura também apresenta o uso de linhas duplas para identificar participação total – a participação do conjunto de entidades (fracas) pagamento no relacionamento pagamento_empréstimo é total, significando que todo o pagamento precisa estar relacionado via pagamento_empréstimo a alguma conta.

Página 32


2.4 Relacionamentos Reflexivos (auto-relacionamento)São os relacionamentos que ocorrem entre as ocorrências de uma mesma entidade. Normalmente eles representam algum tipo de hierarquia.

Funcionário gerencia 0 ou muitos funcionários.

Funcionário é gerenciado por um único funcionário.

2.5 Extensões do Modelo Entidade x RelacionamentoO modelo de dados Entidade x Relacionamentos, como proposto por Peter Chen, tem sido usado efetivamente para a comunicação do usuário final, apresentando entidades e relacionamentos. Entretanto, quando usado para integrar diferentes modelos conceituais com diferentes usuários finais, fica severamente limitado até que se utilize um conceito de abstração de dados denominado generalização.

2.5.1 Relacionamentos entre Múltiplas EntidadesAté o momento analisamos apenas situações em que as entidades se relacionam sozinhas ou em pares, este é o principio da descoberta de relacionamentos, a analise de relacionamento em pares, no entanto um relacionamento pode envolver mais de duas entidades, que podem ser três, quatro, cinco ou uma quantidade indeterminada.

Os relacionamentos entre múltiplas entidades expressam um fato em que todas as entidades ocorrem simultaneamente, ou seja, todas as ocorrências do relacionamento possuem, sempre, ligações com todas as

Página 33

1,1

0,NFuncionário

Gerencia

Empréstimo PagamentoPagamento_E

mpréstimo

Número_empréstimo

Total Data_Pagto

Número_pagamento

Total_pagto

Pagamento_empréstimo


entidades envolvidas no relacionamento. Não é possível um relacionamento triplo (Ternário), em um determinado momento, transformar-se em duplo (Binário).

O diagrama abaixo representa uma situação de relacionamento que envolve três entidades simultaneamente, a este tipo de relacionamento triplo, damos o nome de Relacionamento Ternário.

Um técnico que atua em um projeto utiliza um notebook.

Um notebook é utilizado em um projeto por um técnico.

Um técnico com um notebook atua em um projeto.

2.5.1.1 Entidade associativaUm relacionamento é uma associação entre entidades. Na modelagem ER não foi prevista a possibilidade de associar dois relacionamentos entre si. Na pratica, quando estamos construindo um novo modelo ER ou modificando um modelo ER existente, surgem situações em que é desejável permitir a associação de uma entidade a um relacionamento.

Vejamos um exemplo:

Suponha que seja necessário modificar este relacionamento da seguinte forma. É necessário saber que medicamentos existem e que medicamentos foram prescritos em cada consulta. Para saber que medicamentos existem, cria-se uma nova entidade, Medicamento. A questão agora é: com que entidade existente deve estar relacionada a nova entidade? Se Medicamento fosse relacionado a Médico, ter-se-ia apenas a informação de que médico prescreveu que medicamentos, faltando a informação do paciente que os teve prescritos. Por outro lado, se Medicamento fosse relacionado à Paciente, faltaria a informação do Médico que prescreveu o medicamento. Assim, deseja-se relacionar a prescrição do Medicamento à consulta, ou seja, deseja-se relacionar um relacionamento prescrição com da entidade (Medicamento) a um relacionamento (Consulta), o que não está previsto na abordagem ER.

Página 34

Técnico Projetoatua

11

1

Notebook

NNMédico Paciente

Consulta


Para tal, foi criado um conceito especial, o de entidade associativa. Uma entidade associativa nada mais é que a redefinição de um relacionamento, que passa a ser tratado como se fosse também uma entidade. Graficamente isso é feito como mostrado na figura abaixo.

O retângulo desenhado ao redor do relacionamento Consulta indica que este relacionamento passa a ser visto como uma entidade (associativa, já que é baseada em um relacionamento). Sendo Consulta também uma entidade, é possível associa-l através de relacionamentos a outras entidades, conforme a figura apresentada acima.

2.5.1.2 AgregaçãoO termo agregação tem sido utilizado pelas técnicas de modelagem de sistemas nos mais variados conceitos, porém o conceito lançado em Modelagem de Dados refere-se à visão de um relacionamento como um bloco, como alguma coisa que se relaciona com outra, Isso equivale dizer que um relacionamento esta relacionado a outro. Mas, conceitualmente, não existem relacionamentos entre relacionamentos; é uma inverdade conceitual.

Para que exista o relacionamento de uma agregação com outra entidade é necessária a existência de dependência entre os fatos, ou seja, um fato somente acontece após a existência do primeiro fato.

Página 35

NNMédico Paciente

Consulta

Medicamento

Prescrição

N

N


No diagrama abaixo o Serviço só será utilizado quando um cliente se hospedar em um quarto, o relacionamento utiliza depende do relacionamento de hospeda-se.

2.5.1.3 Generalização (Supertipos) e Especialização (Subtipos)Quando estamos em busca da visualização dos dados de um negócio, é importante atentar ao nível de abstração em que estamos atuando, pois quando definimos uma entidade, estamos com a visão de uma classe genérica de dados que pode estar incorporando, diversas outras classes de dados.

2.5.1.3.1 GeneralizaçãoAo buscarmos as entidades presentes em um dado negócio, pode ser realizado de modo bottom-up (baixo para cima), no qual podemos reconhecer vários conjuntos de entidades com atributos em comum, então, estes atributos comuns são sintetizados em um conjunto de entidades de alto nível.

Por exemplo, ao modelarmos um sistema hospitalar, podemos encontrar entidades como Pediatra, Neurologista, Cardiologista, Clínico Geral, entre outros, e ao analisarmos as características de cada entidade, podemos perceber atributos em comum como nome, sexo, data nascimento e tratando tais entidades de forma mais genérica, podemos concluir que todas estas pessoas são médicos.

Dentro do contexto de modelagem botton-up, alguns autores classificam a entidade generalizada “médico” como um supertipo.

Página 36

N

N

N NCliente QuartoHospeda-se

Serviços

Utiliza


Então podemos ter como regra que ao encontrar um conjunto de entidades que possuem o mesmo conjunto de atributos para descrevê-las, podemos generalizá-las em uma única entidade, mantendo sua identidade de subconjunto pela inserção de um atributo qualificador para as ocorrências de cada uma.

2.5.1.3.2 EspecializaçãoA especialização é justamente o inverso da generalização que é o processo de analise botton-up (de baixo para cima) tratado, ao tratarmos da especialização, nos ocorre o processo inverso de análise o processo top-down (de cima para baixo) que é o caso da especialização, ou seja, um conjunto de entidades pode conter subgrupos (subtipos) de entidades que são de alguma forma, diferentes de outras entidades do conjunto, continuando com o exemplo do digrama anterior, ao analisarmos nossa entidade a partir de médico, pode-se reconhecer subgrupos (subtipos) de médico, como Pediatra, Neurologista, Cardiologista, Clínico Geral, entre outros.

2.5.1.3.3 Generalização X EspecializaçãoNa pratica, a generalização é o inverso da especialização. No processo de modelagem novos níveis de representação serão, diferenciadas (especialização) ou sintetizadas (generalização).

Generalização Especialização

Médico Pediatra, Neurologista, Cardiologista, Clínico Geral

Página 37

Médico

Pediatra Neurologista Clínico Geral Cardiologista


3. Bancos de Dados Relacionais

3.1 DefiniçãoFoi criado por Edgar F. Codd na década de 70. A abordagem relacional está baseada no princípio de que as informações em uma base de dados podem ser consideradas como relações matemáticas e que estão representadas de maneira uniforme, através do uso de tabelas bidimensionais. Este princípio coloca os dados (entidades e relacionamentos) dirigidos para estruturas mais simples de armazenar dados, que são as tabelas, e nas quais a visão do usuário é privilegiada.

A grande diferença existente quando se trabalha com bancos de dados relacionais em relação aos ambientes tradicionais, pode ser exemplificada da seguinte forma:

Em um ambiente tradicional, a função de acender um fósforo seria descrita de forma exatamente procedural, passo a passo:

Abrir a caixa de fósforos. Verificar se existem palitos. Levar o palito à lateral da caixa. Riscar o palito. Testar se acendeu ou não. Etc.

Em um ambiente de banco de dados relacional devemos mentalizar que as instruções todas se resumem em uma única, uma operação realizada em conjunto.

ACENDA UM FÓSFORO

Para definir e explicar claramente suponhamos que queremos retirar de uma sala de aula todos os alunos que possuem média abaixo de 5 pontos.

Em um ambiente tradicional seria perguntado a cada aluno:

Sua média é abaixo de 5 ?

Se a resposta for sim, pediríamos que saísse. Se fosse não, ele ficaria.

Em um ambiente de banco de dados relacional, bastaria realizar uma operação lógica:

Saiam todos que possuam média menor do que 5.

Página 38


3.2 Tabela RelacionalApresentamos abaixo uma relação de conceitos que definem uma tabela relacional:

Cada tabela é chamada de relação. Uma linha e suas colunas chamam-se tupla. Cada coluna dessa tabela tem um nome e representa um atributo da

tabela. A ordem das linhas é irrelevante. Não há duas linhas iguais. A ordem das colunas também é irrelevante. Cada tabela tem nome próprio, distinto de qualquer outra tabela no

banco de dados.

Exemplo: Tabela de Funcionários:

Nome Sexo Matrícula Departamento CargoJoão Carlos M 373 TI-Operações OperadorCarlos Brito M 872 TI-Programação Programador ISilvia Moraes F 963 TI-Análise Analista Sist. IICláudia Tereza F 161 TI-Gerência SecretáriaPedro Júlio M 292 RH DiretorPedro Júlio M 574 TI-Análise Analista Sist. I

Vamos analisar os dados:

As matrículas não indicam a ordem das linhas, apresentando o conceito de que a ordem das linhas é irrelevante.

Todas as colunas possuem um nome que significam algo.

A ordem das colunas não está desenvolvida para nenhuma finalidade de classificação ou ordem de leitura dos dados.

Nenhuma linha se repete.

Podemos ter duas pessoas com o mesmo nome, porém com matrículas diferentes.

Página 39


3.3 O conceito de Chave no Modelo Relacional

3.3.1 Chave Primária (Primary Key)Em uma tabela existe uma coluna ou conjunto de colunas concatenados, cujo valor é único na tabela, ou seja, nunca se repete aquele valor em nenhuma outra linha da tabela, e que identifica uma e somente uma única linha da tabela.

Então dizemos que esta coluna ou conjunto de colunas forma a chave primária da tabela.

Na nossa tabela de funcionário, qual coluna ou conjunto de colunas concatenadas forma um identificador único para cada linha da tabela?

Nome Sexo Matrícula Departamento CargoJoão Carlos M 373 TI-Operações OperadorCarlos Brito M 872 TI-Programação Programador ISilvia Moraes F 963 TI-Análise Analista Sist. IICláudia Tereza F 161 TI-Gerência SecretáriaPedro Júlio M 292 RH DiretorPedro Júlio M 574 TI-Análise Analista Sist. I

Nome? Com certeza não, pois se repete.

Sexo? Também se repete.

Departamento também não e cargo e salário sozinhos também não nos dizem nada.

Sobra neste caso a única coluna que não tem valores repetidos, que é a matrícula.

Existe somente um valor de matrícula para cada linha, o qual não se repete, logo podemos determinar que a Matrícula é a chave primária da tabela de Funcionários.

Vamos agora observar uma tabela mais complicada, em que tenhamos que realizar um estudo maior para determinar a chave primária.

Página 40


Tabela de Consumos

Bebida Qtde Valor Unit.

Local Consumo

Quarto Data Hora Valor

Cerveja 2 3,00 Restaurante 101 22/01/2001 14:30 6,00Chopp 3 2,00 Bar 203 19/01/2001 11:00 8,00Cerveja 2 3,00 Restaurante 101 23/01/2001 14:30 6,00Refrigerante

3 2,00 Restaurante 203 20/01/2001 08:45 6,00Mate 1 1,50 Frigobar 407 21/01/2001 16:30 1,50Café 1 0,80 Restaurante 203 18/01/2001 08:00 0,80Suco 1 3,00 Service Room 505 22/01/2001 21:30 3,00Mate 1 1,50 Restaurante 407 21/01/2001 16:30 1,50Chopp 4 2,00 Bar 203 19/01/2001 17:10 8,00Água 1 1,00 Frigobar 101 18/01/2001 08:30 1,00Café 1 0,80 Restaurante 203 18/01/2001 18:00 0,80

Qual coluna ou conjunto de colunas poderíamos definir como identificador único de cada linha da tabela ?

Poderia ser bebida? Não. Quarto, também não. Notem que nenhuma coluna sozinha poderia ser um identificador único da tabela.

E se utilizarmos bebida e quarto? Note que a bebida cerveja foi consumida pelo quarto 101 mais de uma vez:


Local Consumo


Cerveja 2 3,00 Restaurante 101 22/01/2001 14:30 6,00Cerveja 2 3,00 Restaurante 101 23/01/2001 14:30 6,00

Se acrescentarmos o local de consumo à concatenação das colunas referidas, ainda não teríamos um identificador único.


Local Consumo



Como os consumos foram realizados em datas diferentes, podemos inserir a data na composição da chave primária.


Local Consumo



Desta vez os valores não se repetiriam. Porém, observe o consumo de mate pelo quarto 407.

Página 41



Local Consumo

Quarto Data Consumo

Hora Consumo

Valor Total

Mate 1 1,50 Frigobar 407 21/01/2001 16:30 1,50Mate 1 1,50 Restaurante 407 21/01/2001 16:30 1,50

Eles foram consumidos na mesma data, mas como o local de consumo é diferente, isso garante a integridade de nossa chave primária. Porém, o mesmo não ocorre com as duas linhas a seguir:


Local Consumo

Quarto Data Consumo

Hora Consumo

Valor Total

Café 1 0,80 Restaurante 203 18/01/2001 08:00 0,80Café 1 0,80 Restaurante 203 18/01/2001 18:00 0,80

Aconteceram dois consumos de café pelo mesmo quarto (hóspede), no mesmo local e na mesma data. Isso nos diz que a chave primária definida até agora não está correta, pois existem linhas duplicadas para ela.

Voltando a analisar as duas linhas acima, verificamos que o consumo foi realizado em horas diferentes. Dessa forma, se acrescentarmos a coluna “hora consumo” em nossa chave primária, passaríamos a ter duas linhas distintas.


Local Consumo

Quarto Data Consumo

Hora Consumo

Valor Total

Café 1 0,80 Restaurante 203 18/01/2001 08:00 0,80Café 1 0,80 Restaurante 203 18/01/2001 18:00 0,80

Essa então é a nossa chave primária:

Bebida Local de consumo Quarto Data consumo Hora consumo

Dessa forma, não poderíamos ter a mesma bebida, consumida pelo mesmo quarto (hospedagem), no mesmo local, na mesma data e na mesma hora, pois se isso ocorrer, deveremos alterar a quantidade consumida ao invés de inserirmos duas linhas na tabela.

3.3.2 Chave Estrangeira (Foreign Key)Quando dizemos que duas tabelas estão relacionadas através de atributos (colunas) comuns, devemos observar que esta coluna é a chave primária em uma das tabelas. Na outra tabela, este atributo irá caracterizar o que chamamos de chave estrangeira, propiciando assim, uma ligação lógica (relacionamento) entre as tabelas.

Exemplo:

Página 42Departamento Funcionário

Possui


3.3.3

3.3.3 Chave CandidataUma tabela relacional pode assumir alternativas de identificador único, ou seja, vária colunas ou concatenações delas podem ter essa propriedade. Estes identificadores são candidatos à chave primária. Como somente um poderá ser o escolhido (uma tabela só pode ter uma chave primária – que pode ser composta pela concatenação de mais de uma coluna), o restante passa a ser considerado como chave alternativa (secundária).

3.3.4 Chave Secundária (Secundary Key)Serve para definir uma “segunda chave primária” através da criação de índices únicos de pesquisa. As chaves secundárias mantêm a integridade das tabelas que possuem mais de uma chave candidata.

3.4 Regras de Integridade do Modelo Relacional

3.4.1 Integridade de IdentidadeA chave primária não pode conter um valor nulo (NULL). O NULL não é o valor zero nem o caractere branco, é simplesmente a não existência de conteúdo nesse campo.

3.4.2 Integridade ReferencialSe uma determinada tabela A possui uma chave estrangeira, a qual é chave primária em outra tabela B, então ela deve ser:

Igual a um valor de chave primária existente em B. Nula (null).

Não pode existir na chave estrangeira, um valor que não exista na tabela na qual ela é chave primária.

As regras de integridade do modelo relacional representam a garantia de que as tabelas guardam informações compatíveis. São de extrema importância para a confiabilidade das informações contidas no banco de dados.

Página 43

Cód_Depto Departamento1 TI-Análise2 TI-Programação3 TI-Operações4 RH5 TI-Gerência

Nome Sexo Matrícula DeptoJoão Carlos M 373 3Carlos Brito M 872 2Silvia Moraes F 963 1Cláudia Tereza F 161 5Pedro Júlio M 292 4Pedro Júlio M 574 1

Chave primária Chave estrangeira


3.5 Características do Modelo Relacional Uma tabela é acessível por qualquer campo (atributo) independente se

este é declarado como chave ou não. O relacionamento entre as tabelas não existe fisicamente, pois este

relacionamento é apenas lógico e representado através das chaves estrangeiras.

Utilização de linguagens não procedurais (SQL). Os ambientes relacionais possuem um otimizador estratégico para

escolher o melhor caminho para a recuperação dos dados.

4. Derivação do Modelo Entidade x Relacionamento para o Modelo Lógico Relacional

Nesta etapa o desenvolvedor irá passar a visão do modelo conceitual para o modelo lógico relacional, seguindo algumas regras de conversão.

4.1 Regras de ConversãoExistem regras precisas que não dão margem a erros, sendo que uma vez projetado o diagrama ER, as tabelas que representam o ER num nível mais baixo podem ser obtidas de forma clara.

4.2 Mapeamento de EntidadesToda entidade torna-se uma tabela carregando todos os atributos definidos para ela.

4.3 Mapeando atributosCada atributo vira um campo da tabela criada. Os atributos identificadores viram a chave primária da tabela.

4.4 Relacionamento 1:N (envolvendo entidades distintas)A entidade (tabela) cuja cardinalidade é N recebe o atributo identificador da entidade cuja cardinalidade é 1 (chave estrangeira).

Exemplo:

Página 44

DepartamentoCód_Depto Departamento

1 TI-Análise2 TI-Programação3 TI-Operações4 RH5 TI-Gerência

FuncionárioNome Sexo Matrícula DeptoJoão Carlos M 373 3Carlos Brito M 872 2Silvia Moraes F 963 1Cláudia Tereza F 161 5Pedro Júlio M 292 4Pedro Júlio M 574 1

0,N1,1Departamento FuncionárioPossui

Chave primária Chave estrangeira


4.5 Relacionamento 1:N (envolvendo auto-relacionamento)Incluir a chave primária da entidade na própria entidade como chave estrangeira.

4.6 Relacionamento 1:1As entidades (tabelas) envolvidas neste relacionamento carregarão o identificador da outra (uma ou outra ou ambas) conforme a conveniência do projeto (de acordo com o acesso a essas tabelas).

Podemos colocar a chave matrícula na tabela de departamentos, representando que um departamento possui um chefe.

Página 45

FuncionárioMatrícula Nome Sexo Depto Matrícula_Chefe373 João Carlos M 3 161872 Carlos Brito M 2 161963 Silvia Moraes F 1 161161 Cláudia Tereza F 5 056292 Pedro Júlio M 4 010574 Pedro Júlio M 1 161

FuncionárioNome Sexo Matrícula DeptoJoão Carlos M 373 3Carlos Brito M 872 2Silvia Moraes F 963 1Cláudia Tereza F 161 5Pedro Júlio M 292 4Pedro Júlio M 574 1

DepartamentoCód_Depto Departamento Chefe

1 TI-Análise 5742 TI-Programação 8723 TI-Operações 3734 RH 2925 TI-Gerência 161

1,1

0,N

FuncionárioGerencia

1,1 0,1Funcionário DepartamentoChefia


Podemos também colocar a chave departamento na tabela de funcionários, representando que um funcionário pode chefiar um departamento. Note que podemos ter funcionário que não chefiam nenhum departamento.

Também poderíamos colocar a chave estrangeira em ambas as tabelas (alternativa menos utilizada).

4.7 Relacionamento N:NO relacionamento torna-se uma tabela carregando os atributos identificadores das entidades relacionadas e os atributos do relacionamento (quando houver).

Página 46

DepartamentoCód_Depto Departamento

1 TI-Análise2 TI-Programação3 TI-Operações4 RH5 TI-Gerência

EmpregadoNome Sexo Matrícula Chefia

DeptoTrabalha Depto

João Carlos M 373 3 3Carlos Brito M 872 2Silvia Moraes F 963 1Cláudia Tereza F 161 5 5Pedro Júlio M 292 4Pedro Júlio M 574 1 1

DepartamentoCód_Dept

oDepartamento Chefe

1 TI-Análise 5742 TI-

Programação872

3 TI-Operações 3734 RH 2925 TI-Gerência 161

FuncionárioNome Sexo Matrícula Chefia

DeptoTrabalha Depto

João Carlos M 373 3 3Carlos Brito M 872 2 2Silvia Moraes F 963 1Cláudia Tereza

F 161 5 5Pedro Júlio M 292 4 4Pedro Júlio M 574 1 1

FuncionárioNome Sexo MatrículaJoão Carlos M 373Carlos Brito M 872Silvia Moraes F 963Cláudia Tereza F 161Pedro Júlio M 292Pedro Júlio M 574

ProjetoCód_Projeto Projeto

1 Data Warehouse RH2 Folha de Pagamento3 B.I. Marketing

Projeto_FuncionárioMatrícula Cód_Pojeto Horas_Alocadas

373 1 100872 3 300373 2 200

0,N 0,NFuncionário ProjetoAlocado


4.8 Relacionamento MúltiploO relacionamento é mapeado em uma tabela, cuja chave primária é formada pela concatenação de todas as chaves estrangeiras.

4.9 GeneralizaçõesExemplo:

Dado um conjunto “funcionário”, existe uma variação para este, pois existem funcionários que são engenheiros, outros são vendedores e assim por diante, sendo que podem existir variações nos atributos de um funcionário de acordo com o seu cargo.

O artifício que temos é a criação de subconjuntos para os casos nos quais as informações variam.

Um elemento funcionário só pode ter um e somente um subconjunto. As informações dos engenheiros serão completadas pelo subconjunto “engenheiro”, as do vendedor pelo subconjunto “vendedor” e assim por diante.

Os subconjuntos tornam-se tabelas carregando o identificador do conjunto ao qual pertencem.

Página 47

ProjetoCód_Projeto Projeto

1 Data Warehouse RH2 Folha de Pagamento3 B.I. Marketing

ConhecimentoCód_Conhec Conhecimento

1 Oracle Discovere2 PL/SQL3 SQL Server

FuncionárioNome Sexo MatrículaJoão Carlos M 373Carlos Brito M 872Silvia Moraes F 963Cláudia Tereza F 161Pedro Júlio M 292Pedro Júlio M 574

Funcionário-Projeto-ConhecimentoMatrícula Cód_Pojeto Cód_conhec

373 1 1872 3 2574 2 3574 2 2

0,N

0,N 0,NFuncionário ProjetoAlocado

Conhecimento

Funcionário

EngenheiroGerente Secretária

- Matrícula

- Ajuda de custo

- Especialidade

- Matrícula

- Hora Extra

- Despesa Extra

- Placa Carro

- Matrícula

- Língua Estrangeira

- Curso


Página 48


FuncionárioMatrícula Nome Função4534 Soraia Mattos Ger6547 Breno Medeiros Eng7734 Gustavo Borges Eng1198 Ana Ferreira Eng3289 Telma Ribeiro Sec

5. Normalização de Dados

5.1 DefiniçãoO conceito de normalização foi introduzido por E. F. Codd em 1972.

Inicialmente Codd criou as três primeiras formas de normalização chamando-as de: primeira forma normal (1NF), segunda forma normal (2NF) e terceira forma normal (3NF). Uma definição mais forte da 3NF foi proposta depois por Boyce-Codd, e é conhecida como forma normal de Boyce-Codd (FNBC).

Através do processo de normalização pode-se, gradativamente, substituir um conjunto de entidades e relacionamentos por um outro, o qual se apresenta "purificado" em relação às anomalias de atualização (inclusão, alteração e exclusão) as quais podem causar certos problemas, tais como:

grupos repetitivos (atributos multivalorados) de dados; variação temporal de certos atributos, dependências funcionais totais ou

parciais em relação a uma chave concatenada; redundâncias de dados desnecessárias; perdas acidentais de informação; dificuldade na representação de fatos da realidade observada; dependências transitivas entre atributos.

Normalização de relações é portanto uma técnica que permite depurar um projeto de banco de dados, através da identificação de inconsistências (informações em duplicidade, dependências funcionais mal resolvidas, etc).

Página 49

Func_GerenteMat Aj Custo Espec4534 120 Eletr.

Func_SecretariaMat Língua Curso4534 Inglês Secret.

Func_EngenheiroMat HR Ext Desp Ext Placa4534 120 240 AHA89097734 ACA23563289 5 23 JOL1234


À medida que um conjunto de relações passa para uma forma normal, vamos construindo um banco de dados mais confiável.

O objetivo da normalização não é eliminar todas as inconsistências, e sim controlá-las.

5.2 Primeira Forma Normal (1FN)Uma relação está na primeira forma normal se os valores de seus atributos são atômicos (simples, indivisíveis) e monovalorados. Em outras palavras, FN1 não permite “relações dentro de relações” ou “relações como atributos de tuplas”.

Uma tabela está na primeira forma normal quando seus atributos não contêm grupos de repetição.

Exemplo:

Estrutura original:

Arquivo de Vendas (Num Venda, Data emissão, Cod. do Cliente, Nome do cliente, Endereço do cliente, CGC do cliente, Relação das mercadorias vendidas (onde para cada mercadoria temos: Código da Mercadoria, Descrição da Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta mercadoria) e Total Geral da Nota).

Analisando a estrutura acima, observamos que existem várias mercadorias em uma única Venda, sendo, portanto elementos repetitivos que deverão ser retirados.

Estrutura na primeira forma normal (1FN):

Arquivo de Vendas (Num Venda, Data emissão, Código do Cliente, Nome Cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota).

Arquivo de Itens da Venda (Num Venda, Código da Mercadoria, Descrição da Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta mercadoria)

Obs. Os campos sublinhados identificam as chaves das estruturas.

Como resultado desta etapa ocorre um desdobramento dos dados em duas estruturas, a saber:

Primeira estrutura (Arquivo de Vendas): Dados que compõem a estrutura original, excluindo os elementos repetitivos.

Segundo estrutura (Arquivo de Itens da Venda): Dados que compõem os elementos repetitivos da estrutura original, tendo como chave o campo chave da estrutura original (Num Venda) e o campo chave da estrutura de repetição (Código da Mercadoria).

5.3 Segunda Forma Normal (2FN) - Dependências FuncionaisPara uma tabela estar na segunda forma normal, além de estar na primeira forma ela não deve conter dependências funcionais de parte da chave primária. Um jeito de verificar esta norma é refazer a leitura dos campos fazendo a

Página 50


pergunta: Este campo depende de toda a chave? Se não depender de toda a chave temos uma dependência funcional.

Exemplo:

Estrutura na primeira forma normal (1FN):

Arquivo de Vendas (Num Venda, Data emissão, Código do Cliente, Nome do cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota).

Arquivo de da Itens Vendas (Num Venda, Código da Mercadoria, Descrição da Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta mercadoria)

Estrutura na segunda forma normal (2FN):


Arquivo de Itens da Vendas (Num Venda, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria).

Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço de venda).

Como resultado desta etapa, houve um desdobramento do arquivo de Itens da Venda (o arquivo de Vendas, não foi alterado, por não possuir chave composta) em duas estruturas a saber:

Primeira estrutura (Arquivo de Itens da Vendas): Contém os elementos originais, sendo excluídos os dados que são dependentes apenas do campo Código da Mercadoria.

Segundo estrutura (Arquivo de Mercadorias): Contém os elementos que são identificados apenas pelo Código da Mercadoria, ou seja, independentemente da Nota Fiscal, a descrição e o preço de venda serão constantes.

5.4 - Terceira Forma Normal (3FN) - Dependências TransitivasPara uma tabela estar na terceira forma normal, além de estar na segunda forma ela não deve conter dependências transitivas. Um jeito de verificar esta norma é refazer a leitura dos campos fazendo a pergunta: Este campo depende de outro que não seja a chave? Se ele depender temos uma dependência transitiva..

Página 51


Exemplo:

Estrutura na segunda forma normal (2FN):


Arquivo de Itens da Venda (Num Venda, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria).


Estrutura na terceira forma normal (3FN):

Arquivo de Vendas (Num Venda, Data emissão, Código do Cliente e Total Geral da Nota).

Arquivo de Itens da Venda (Num Venda, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria).


Arquivo de Clientes (Código do Cliente, Nome do cliente, Endereço do cliente e CGC do cliente).

Como resultado desta etapa, houve um desdobramento do arquivo de Vendas, por ser o único que possuía campos que não eram dependentes da chave principal (Num Venda), uma vez que independente da Venda, o Nome, Endereço e CGC do cliente são inalterados. Este procedimento permite evitar inconsistência nos dados dos arquivos e economizar espaço por eliminar o armazenamento freqüente e repetidas vezes destes dados. A cada venda feita para o cliente, haverá o armazenamento destes dados e poderá ocorrer divergência entre eles.

As estruturas alteradas foram pelos motivos, a saber:

Primeira estrutura (Arquivo de Vendas): Contém os elementos originais, sendo excluídos os dados que são dependentes apenas do campo Código do Cliente (informações referentes ao cliente).

Segundo estrutura (Arquivo de Clientes): Contém os elementos que são identificados apenas pelo Código do Cliente, ou seja, independente da Venda, o Nome, Endereço e CGC dos clientes serão constantes.

Após a normalização, as estruturas dos dados estão projetadas para eliminar as inconsistências e redundâncias dos dados, eliminando desta forma qualquer problema de atualização e operacionalização do sistema. A versão final dos dados poderá sofrer alguma alteração, para atender as necessidades específicas do sistema, a critério do analista de desenvolvimento durante o projeto.

5.5 Quarta Forma Normal (4FN)Na grande maioria dos casos, as entidades normalizadas até a 3FN são fáceis de entender, atualizar e de se recuperar dados. Mas às vezes podem surgir problemas com relação a algum atributo não chave, que recebe valores

Página 52


múltiplos para um mesmo valor de chave. Esta nova dependência recebe o nome de dependência multivalorada que existe somente se a entidade contiver no mínimo três atributos.

Uma entidade que esteja na 3FN também estará na 4FN, se ela não contiver mais do que um fato multivalorado a respeito da entidade descrita.

Exemplo: Dado a tabela a seguir.

Cód Funcionário Habilidade Idioma1234 SQL Server Inglês1234 Oracle Francês1234 Oracle Inglês1234 Access Alemão

Como podemos observar, esta entidade tenta conter dois fatos multivalorados: as diversas habilidades de um funcionário e os diversos idiomas. Com isso apresenta uma dependência multivalorada entre Código Funcionário e Habilidade e entre Código Funcionário e Idioma. Embora esteja na 3FN, ao conter mais de um fato multivalor, torna a sua atualização muito difícil.

Para passarmos a entidade acima para a 4FN, é necessária a realização de uma divisão da entidade original, em duas outras entidades, ambas herdando a chave Código Funcionário e concatenado, em cada nova entidade, com os atributos Habilidade e Idioma.

Funcionário-Habilidade

Cód Funcionário Habilidade1234 SQL Server1234 Oracle1234 Access

Funcionário -Idioma

Cód Funcionário Idioma1234 Inglês1234 Francês1234 Alemão

Página 53


5.6 Quinta Forma Normal (5FN)Um registro não pode ser reconstruído a partir de vários tipos de registros menores.

Exemplo:

Os vendedores representam as empresas. As empresas fazem produtos. Os vendedores vendem os produtos.

Caso mais geral (permite qualquer combinação):

Vendedor Empresa ProdutoSmith Ford CarroSmith GM Caminhão

O Smith não vende nem caminhões da Ford, nem carros da GM.

É em uma alteração que ocorre o problema:

Se um vendedor trabalha com um determinado produto, e ele representa uma empresa, então ele vende esses produtos pela empresa.

Vendedor Empresa ProdutoSmith Ford CarroSmith Ford CaminhãoSmith GM CarroSmith GM CaminhãoJones Ford Carro

Podemos reconstruir todos os fatos verdadeiros em três tabelas em vez de uma:

Vendedor EmpresaSmith FordSmith GMJones Ford

Problemas com a forma da tabela 1:

Página 54

Empresa ProdutoFord CarroFord CaminhãoGM CarroGM Caminhão

Vendedor ProdutoSmith CarroSmith CaminhãoJones Carro


Os fatos são registrados várias vezes. Por exemplo, o fato de que o Smith vende carros é registrado duas vezes. Se Smith parar de vender carros, 2 linhas devem ser atualizadas e faltará uma.

O tamanho desta tabela aumenta em progressão geométrica, enquanto as tabelas normalizadas crescem em progressão aritmética. Para grandes operações, isso faz uma grande diferença: 100.000 x 100.000 é bem maior do que 100.000 + 100.000.

É mais fácil escrever as regras comerciais a partir da quinta normal:

As regras são mais explícitas. (Cadeias de suprimentos têm todos os tipos de problemas da 5FN).

Um exemplo de um conjunto sutil de condições:

Não-normal

Vendedor Empresa ProdutoSmith Ford CarroSmith Ford CaminhãoSmith GM CarroSmith GM CaminhãoJones Ford CarroJones Ford CaminhãoBrown Ford CarroBrown GM CarroBrown Toyota CarroBrown Toyota Ônibus

Na 5FN:

Jones vende carros e a GM fabrica carros, mas Jones não é representante da GM.

Brown é representante da Ford e a Ford fabrica caminhões, mas Brown não vende caminhões.

Brown é representante da Ford e Brown vende ônibus, mas a Ford não fabrica ônibus.

Página 55

Vendedor EmpresaSmith FordSmith GMJones FordBrown FordBrown GMBrown Toyota

Empresa ProdutoFord CarroFord CaminhãoGM CarroGM CaminhãoToyota CarroToyota Ônibus

Vendedor ProdutoSmith CarroSmith CaminhãoJones CarroJones CaminhãoBrown CarroBrown Ônibus


Bibliografia

C. J. Date - Introdução a Sistemas de Banco de Dados, Elsevier 8º Edição

Paulo Cougo - Modelagem Conceitual e Projeto de Bancos de dados, Elsevier17º Triagem

Felipe Machado e Maurício Abreu - Projeto de Banco de Dados Uma Visão Prática, Érica

ABRAHAM SILBERSCHATZ, HENRY F., S. SUDARSHAN - Sistemas de Banco de dados, Makron Books

Ramez Elmasri, Shamkant Navathe - Fundamentals of Database Systems; The Benjamin CummingsPublishing Company; 1989;

KROENKE, DAVID M. - Banco de Dados: Fundamentos, projeto e implementação. Sexta edição (tradução). LTC 1999

Carlos Alberto Heuser – Projeto de Banco de dados, Bookman.

Fernando Martins de Oliveira – Apostila Banco de Dados.

Shigueru Watanabe – Aulas e apresentações de Banco de Dados.

http://www.ime.usp.br/~andrers/aulas/bd2005-1/aula.htmlhttp://www.criarweb.com/artigos/modelos-banco-dados.html

Página 56

Documents

Administração e Projeto de banco de dados - Turma 3B€¦ · Web viewAdministração e Projeto de banco de dados. ... O modelo em redes surgiu como uma extensão ao modelo hierárquico,