ex modelagem good

8/3/2019 Ex Modelagem Good

http://slidepdf.com/reader/full/ex-modelagem-good 1/57

Administração e Projeto de Banco de Dados

Rudson Kiyoshi Souza Carvalho Página 1

Administração eProjeto debanco de dados 2010Conceito de banco de dados. Modelagem conceitual dedados. Formas normais. Projeto lógico e físico, segundo omodelo relacional. Linguagem de definição e manipulaçãode dados. O padrão SQL. Concorrência de transações emecanismos de manutenção de integridade, em sistemasde banco de dados. Views, Triggers, e Stored Procedures.Segurança e controle de acesso a informação.

Sistemas deInformação eProcessamento dedados




Conteúdo

Conteúdo ................................................................................. 2

Introdução e conceitos gerais .................................................5

Banco de dados ........................................................................................ 5

Sistema de Banco de Dados ...................................................................... 6Principais componentes de um Sistema de Banco de Dados ...........................6Dados .....................................................................................................6Hardware ................................................................................................7Software .................................................................................................7Usuários ..................................................................................................7Usuários finais: .......................................................................................8

Administrador de Banco de Dados (DBA) .....................................................8Projetista de Banco de Dados (Administrador de Dados) ................................8Analistas de Sistemas e Programadores de Aplicações ..................................8Por que um Sistema de Banco de Dados? ....................................................9Vantagens tecnológicas da utilização de um Sistema de Banco de Dados .........9Quando não Utilizar um SGBD .................................................................. 10Arquitetura de sistemas de banco de dados. .............................................. 11Os três níveis da arquitetura: ................................................................... 11Independência de Dados ......................................................................... 12

Sistema de Gerenciamento de Bancos de Dados (SGBD) ........................ 13

Funções do SGBD ................................................................................... 13Estrutura geral do SGBD .......................................................................... 13

Linguagens para Manipulação de Dados ................................................. 16Modelos de Bancos de Dados ................................................................... 17O Modelo Hierárquico .............................................................................. 17O modelo de Rede .................................................................................. 18O Modelo Relacional................................................................................ 19O Modelo Orientado a Objetos .................................................................. 20

Modelagem de Dados ............................................................. 21Modelo Conceitual de Dados (MCD) ........................................................... 21

Modelo Lógico de Dados (MLD) ................................................................. 22Modelo Físico de Dados (MFD) .................................................................. 22

Modelo E-R ............................................................................................. 22Entidade ................................................................................................ 24Atributo ................................................................................................. 25Descritivo: ............................................................................................. 25Identificador: ......................................................................................... 25Composto: ............................................................................................. 25Derivado: .............................................................................................. 25Multivalorado: ........................................................................................ 25

Relacionamento ...................................................................................... 26Grau do Relacionamento ou Cardinalidade ................................................. 27





Relacionamento Um-para-Um (1:1) .......................................................... 27Relacionamento Um-para-Muitos (1:N) ...................................................... 28Relacionamento Muitos-para-Muitos (N:N) ................................................. 29Participação ........................................................................................... 30Relacionamentos Reflexivos (auto-relacionamento) ..................................... 32

Extensões do Modelo Entidade x Relacionamento .................................. 32Relacionamentos entre Múltiplas Entidades ................................................ 32Entidade associativa ................................................................................ 33Agregação ............................................................................................. 34Generalização (Supertipos) e Especialização (Subtipos) ............................... 35Generalização ........................................................................................ 35Especialização ........................................................................................ 36Generalização X Especialização ................................................................. 36

Bancos de Dados Relacionais ................................................. 37

Definição ................................................................................................ 37Tabela Relacional................................................................................... 38

O conceito de Chave no Modelo Relacional............................................. 39Chave Primária (Primary Key) .................................................................. 39Chave Estrangeira (Foreign Key) .............................................................. 41Chave Candidata .................................................................................... 42Chave Secundária (Secundary Key) .......................................................... 42

Regras de Integridade do Modelo Relacional.......................................... 42Integridade de Identidade ....................................................................... 42

Integridade Referencial........................................................................... 42

Características do Modelo Relacional..................................................... 43

Derivação do Modelo Entidade x Relacionamento para o

Modelo Lógico Relacional ....................................................... 43

Regras de Conversão .............................................................................. 43Mapeamento de Entidades ....................................................................... 43Mapeando atributos ................................................................................ 43Relacionamento 1:N (envolvendo entidades distintas) ................................. 43Relacionamento 1:N (envolvendo auto-relacionamento) .............................. 44Relacionamento 1:1 ................................................................................ 44Relacionamento N:N ............................................................................... 46Relacionamento Múltiplo .......................................................................... 46Generalizações ....................................................................................... 47

Normalização de Dados ........................................................ 49

Definição ................................................................................................ 49Primeira Forma Normal (1FN) ................................................................... 50Segunda Forma Normal (2FN) - Dependências Funcionais ............................ 51- Terceira Forma Normal (3FN) - Dependências Transitivas .......................... 51Quarta Forma Normal (4FN) ..................................................................... 53

Quinta Forma Normal (5FN) ..................................................................... 54Bibliografia ............................................................................................ 57





Introdução e conceitos gerais

Antes de definir banco de dados, vamos definir alguns conceitos básicos ligadosao mesmo, como dado, informação e conhecimento.

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

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

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

compartilhar a informação.

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

Banco de dados

Um “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 significadoimplícito. Porém, o significado do termo “banco de dados” é mais restrito quesimplesmente a definição dada acima. Um banco de dados possui as seguintespropriedades:

• um banco de dados é uma coleção lógica coerente de dados com umsignificado inerente; uma disposição desordenada dos dados não pode serreferenciada como um banco de dados;

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





• 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çõesdesenvolvidas especialmente para esta tarefa ou por um “Sistema Gerenciador

de Banco de Dados” (SGBD). Um SGBD permite aos usuários criarem emanipularem bancos de dados de propósito gerais. O conjunto formado por umbanco de dados mais as aplicações que manipulam o mesmo é chamado de

“Sistema de Banco de Dados”.

Sistema de Banco de Dados

Segundo C. J. Date um sistema de banco de dados é basicamente umsistema computadorizado de manutenção de registros. O banco de dados, por sisó, pode ser considerado como o equivalente eletrônico de um armário dearquivamento, ou seja, ele é um repositório ou recipiente para uma coleção dearquivos de dados computadorizados, de modo geral a finalidade de um bancode dados é armazenar informações e permitir que os usuários busquem eatualizem essas informações quando forem requisitadas. As informações emquestã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 podemrealizar (ou melhor, solicitar que o sistema realize) diversas operaçõesenvolvendo 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

Principais componentes de um Sistema de Banco de Dados

Um sistema de banco de dados envolve 4 componentes principais:

• Dados• Hardware• Software• Usuários

Dados

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

Os dados em um sistema de banco de dados são integrados ecompartilhados





Por integrado, queremos dizer que o banco de dados pode ser consideradocomo 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.

Por compartilhado, queremos dizer que o banco de dados pode ser

compartilhado entre diferentes usuários, no sentido de que diferentes usuáriospodem ter acesso aos mesmos dados, possivelmente ao mesmo tempo (acessoconcorrente).

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çãorefere-se ao significado desses dados para determinado usuário. Por exemplo,se armazenamos no banco de dados a data de nascimento de um cliente comosendo 10/01/1970, esse dado nos da a informação que em 20/12/1990 essecliente estava com 20 anos.

Hardware

Os componentes de hardware do sistema de banco de dados consistem em:

• Volumes de armazenamento secundário – normalmente discosmagné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 eassim por diante.

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

Software

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

Usuários

Os usuários (finais) acessam o banco de dados interativamente através dealguma aplicação ou interface on-line que na maioria das vezes podem seroferecidas pelo fornecedor do SGBD estas aplicações são internas (built-in), enão escrita pelos usuários, a maior parte dos sistemas possui pelo menos umaaplicação built-in, chamada de processador de linguagem de consulta, por meiodo qual o usuário pode emitir requisições ao banco de dados.

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





Usuários finais:

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

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

• Usuários novatos ou paramétricos: utilizam porções pré-definidasdo banco de dados, utilizando consultas pré-estabelecidas que foramexaustivamente testadas;

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

Administrador de Banco de Dados (DBA)

Em um ambiente de banco de dados, o recurso primário é o banco de dados porsi só e o recurso secundário o SGBD e os softwares relacionados. Aadministração destes recursos cabe ao Administrador de Banco de Dados, oqual é responsável pela autorização de acesso ao banco de dados e pelacoordenaçã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.

Projetista de Banco de Dados (Administrador de Dados)

O Projetista de Banco de Dados é responsável pela identificação dos dados quedevem ser armazenados no banco de dados, escolhendo a estrutura corretapara representar e armazenar dados. Muitas vezes, os projetistas de banco dedados atuam como “staff” do DBA, assumindo outras responsabilidades após a

construção do banco de dados. É função do projetista também avaliar asnecessidades de cada grupo de usuários para definir as visões que serãonecessárias, integrando-as, fazendo com que o banco de dados seja capaz deatender a todas as necessidades dos usuários.

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

Analistas de Sistemas e Programadores de Aplicações

Os analistas determinam os requisitos dos usuários finais e desenvolvemespecificações para transações que atendam estes requisitos, e osprogramadores são os responsáveis pelo desenvolvimento de aplicações em

linguagens como Java, Cobol, C#, C++, VB.net e etc. que fazem chamadas ourequisições ao SGBD através de instruções SQL





Por que um Sistema de Banco de Dados?

As vantagens de um sistema de banco de dados em relação aos métodostradicionais, 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 umavelocidade muito maior do que o ser humano.

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

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

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çãoem locais diferentes, provocando inconsistências. Em um Banco deDados 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áriosacessem o banco de dados ao mesmo tempo. Este fator é essencial paraque múltiplas aplicações integradas possam acessar o banco.

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

• Restrição a Acesso não Autorizado

O banco de dados deve dispor de recursos que possibilitem selecionar aautoridade de cada usuário. Assim um usuário poderá realizar qualquer

tipo de acesso, outros poderão ler alguns dados e atualizar outros eoutros ainda poderão somente acessar um conjunto restrito de dadospara escrita e leitura.

• Tolerância a Falhas

Um banco de dados deve fornecer recursos para recuperação de falhastanto 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

Uma transação é uma unidade lógica de trabalho (mais precisamente,uma unidade lógica de trabalho de banco de dados), em geralenvolvendo diversas operações de banco de dados, onde uma operação

só pode ser validada pelo banco de dados se todas as demais operaçõesda transação também o forem.

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

Quando não Utilizar um SGBD

Em algumas situações, o uso de um SGBD pode representar uma cargadesnecessária aos custos quando comparado à abordagem processamentotradicional de arquivos como, por exemplo:

• Alto investimento inicial na compra de software e hardwareadicionais;

• Generalidade que um SGBD fornece na definição e processamento dedados;

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

• Problemas adicionais podem surgir caso os projetistas de banco dedados ou os administradores de banco de dados não elaborem os

projetos corretamente ou se as aplicações não são implementadas deforma apropriada. Se o DBA não administrar o banco de dados de formaapropriada, tanto a segurança quanto a integridade dos sistemas podemser comprometidas. A sobrecarga causada pelo uso de um SGBD e a máadministração justificam a utilização da abordagem processamentotradicional de arquivos em casos como:

• O banco de dados e as aplicações são simples, bem definidas e nãose 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 deum SGBD;

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





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 doStudy Group on Data Base Management Systems para representar os sistemas

de banco de dados. A meta desta arquitetura é separar as aplicações deusuários da base de dados física. Nessa arquitetura a base de dados pode serdefinida em três níveis: Nível Externo, Nível Conceitual e Nível Interno ouFísico.

Os três níveis da arquitetura:

• O nível externo ou visão (também conhecido como nível lógico deusuário) é o mais próximo dos usuários, ou seja, é aquele que se ocupade como os dados são vistos por usuários individuais, como os dadosestão organizados para formar a informação para cada usuário. O nívelexterno possui esquemas externos ou visões e não depende do sistema

gerenciador de banco de dados. Cada esquema descreve a visão dainformaçã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 decomunidade, ou as vezes apenas como nível lógico, sem qualificação)possuí um esquema conceitual que representa a estrutura da base dedados que é o produto da normalização. È uma visão mais apropriadapara os projetistas onde todos os conjuntos de dados do nível externoestão quebrados em pedaços lógicos, fundidos para reduzir repetição, e

estruturados para eliminar dependências. O esquema conceitual é umadescrição global da base de dados, que omite detalhes da estrutura dearmazenamento físico e se concentra na descrição de entidades, tipos dedados, relacionamento e restrições (Diagrama de Entidade eRelacionamento).

• O nível Interno ou Físico (também conhecido como nível dearmazenamento) é o mais próximo do meio de armazenamento físico, ouseja, é aquele que se ocupa do modo como os dados, ou melhor,registros e arquivos são fisicamente armazenados dentro da base dedados e depende fortemente do SGBD selecionado. É uma visão mais

apropriada aos programadores de base de dados. Todos os conjuntos dedados do nível físico estão organizados para aperfeiçoar a velocidade deexecução, maximizar a disponibilidade dos dados, e manter os dadosseguros.





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

Analisando a imagem podemos observar que o nível externo se preocupacom 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 dedados, mas somente acessarão algumas partes das informações contidas nomesmo; assim, haverá muitas “visões externas” distintas, cada qualconsistindo em uma representação abstrata de alguma parte da informaçãocontida no banco de dados, e haverá uma “visão conceitual”, consistindo emuma representação igualmente abstrata do banco de dados em suatotalidade. Do mesmo modo haverá uma “visão interna”, representando omodo como os dados estão armazenados internamente.

Independência de Dados

A “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ívelsuperior (figura anterior). Existem dois tipos de independência de dados:

• Independência de dados lógica: é a capacidade de alterar o esquemaconceitual sem ter que alterar o esquema externo ou as aplicações dousuário, ou seja, podemos alterar o esquema conceitual sem anecessidade de reescrever os programas aplicativos. Algumas vezes énecessário alterar a estrutura lógica do banco de dados como porexemplo 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 ouas aplicações do usuário, ou seja, podemos alterar o esquema físico sem





a necessidade de reescrever os programas aplicativos. Algumas vezessão necessárias modificações no nível físico para melhorar odesempenho.

Sistema de Gerenciamento de Bancos de Dados (SGBD)

Um sistema gerenciador de banco de dados (SGBD) é responsável porarmazenar dados de forma confiável e permitir fácil recuperação e atualizaçãodesses dados. Um SGBD relacional (SGBDR ou RDBMS relational databasemanagement system) armazena dados de forma relacional, isto é na forma delinhas 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 adefinição da estrutura de armazenamento.4. O SGBD realiza as operações solicitadas no banco de dadosarmazenado.

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

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.

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 sistemaoperacional do computador fornece apenas os serviços mais básicos e o sistemade banco de dados precisa ser construído sobre essa base. Portanto, o projetodo sistema de banco de dados precisa incluir considerações sobre a interfaceentre 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 naarmazenagem do disco e as estruturas de dados usadas para representara 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 ede consulta submetidos ao sistema.





• Processador de consultas, que traduz os comandos numa linguagemde consulta para instruções de baixo nível que o gerenciador do banco dedados pode interpretar. Além disso, o processador de consultas tentatransformar uma requisição do usuário em uma forma compatível e maiseficiente com respeito ao banco de dados, encontrando uma boaestratégia para executar a consulta.

• Pré-compilador da DML, que converte comandos da DML embutidosem um aplicativo para chamadas de procedimento normal na linguagemhospedeira. O pré-compilador precisa interagir com o processador deconsultas pra gerar o código apropriado.

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

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

• Arquivos de dados, que armazenam o banco de dados propriamentedito.

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

• Índices, que fornecem acesso rápido aos itens de dados guardandodeterminados valores.

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

Figura 3 Estrutura básica de um SGBD





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

Figura 4 Estrutura expandida de um SGBD





Linguagens para Manipulação de Dados

Quando tratamos de banco de dados, e desejamos criar uma estrutura lógicapara armazenamento e organização destes dados e realizar consultas,

alterações, restrições de acesso, definições de esquemas e etc, fazemos uso deuma linguagem que nos auxilie e facilite realizar esta tarefa.

As Linguagens para Manipulação de Dados são divididas em três grupos decomandos:

• 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 (DataDefinition Language - Linguagem de Definição de Dados). O SGBD possuium compilador DDL que permite a execução das declarações para

identificar as descrições dos esquemas e para armazená-las no catálogodo SGBD.

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

Uma vez que o banco de dados esteja criado, usa-se uma linguagempara 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õesdo banco de dados como a concessão (GRANT) ou revogação (REVOKE)de privilégios no banco de dados.





Modelos de Bancos de Dados

Existem diversos modelos de banco de dados, e cada modelo tem suascaracterísticas de manipulação e armazenamento dos dados, dentre estes

modelos vamos conhecer os quatro principais e mais comuns modelosencontrados no mercado, são eles: o modelo hierárquico, em rede, relacional eorientado 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

O Modelo Hierárquico

O modelo hierárquico é uma coleção de registros conectados uns aos outros pormeio de links. Um registro é, em muitos aspectos, similar a uma entidade domodelo entidade x relacionamento que veremos mais a frente. Cada registro éuma coleção de campos (atributos), cada qual contendo somente um valor. Umlink é uma associação entre exatamente dois registros. Portanto, um link podeser visto como uma forma restrita (binária) de relacionamento no sentido domodelo entidade x relacionamento. Este modelo utiliza árvores para arepresentação lógica dos dados. Esta árvore esta composta de uns elementos

chamados nós. O nível mais alto da árvore denomina-se raiz. Cada nórepresenta um registro com seus correspondentes campos.

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.

Figura 5 Banco de Dados Modelo Hierárquico

Neste modelo só se podem representar relações 1:M (uma para muitos), porisso 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 pelosegmento 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

O modelo de Rede

Um banco de dados de rede é uma coleção de registros conectados uns aos

outros por meio de links. Um registro é, em muitos aspectos, similar a umaentidade do modelo entidade x relacionamento. Cada registro é uma coleção decampos (atributos), cada qual contendo somente um valor. Um link é umaassociação entre exatamente dois registros. Portanto, um link pode ser vistocomo uma forma restrita (binária) de relacionamento no sentido do modeloentidade x relacionamento. Nesta estrutura qualquer componente pode serelacionar com qualquer outro. Diferentemente do modelo hierárquico, nestemodelo, um filho pode ter vários pais.

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)





O Modelo Relacional

O Modelo Relacional de banco de dados é o modelo no qual iremos nosaprofundar nesse curso, por ser um modelo de fácil entendimento e o mais

utilizado atualmente. Ele representa os dados por meio de conceitosmatemáticos da teoria dos conjuntos. Dirigido, este modelo foi proposto pelopesquisador Edgar Ted Frank Codd em jun/1970, este modelo melhora a visãodos dados, a abordagem relacional faz com que o banco de dados sejarepresentado como um conjunto de tabelas bidimensionais, originadas emlinhas e colunas. A relação entre duas tabelas é feita através de colunas emcomum (chave primária e chave estrangeira).

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 degerenciamento.• Os usuários não necessitam saber onde se encontram os dadosfisicamente.

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

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)





O Modelo Orientado a Objetos

É 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 objetoscontinuam a existir mesmo após o encerramento do programa. Através dasconstruções orientadas a objeto, os programadores podem esconder os detalhesda implementação de seus módulos, compartilhar a referência a objetos eexpandir seus sistemas através de módulos existentes. A funcionalidade debanco de dados é necessária para assegurar o compartilhamento concomitantee a continuidade das informações nas aplicações. Através dos bancos de dadosos programadores podem obter o estado em que os objetos se encontram, eestar atualizados entre várias solicitações do programa, e vários usuáriospodem ao mesmo tempo compartilhar a mesma informação. O banco de dadosorientado a objeto combina os benefícios e conceitos da orientação a objetoscom a funcionalidade dos bancos de dados.

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 querecebem as características de seus supertipos.

• O acesso aos dados pode ser rápido porque as junções geralmentenão são necessárias.

Exemplo de banco de dados OO: CACHÉ, VERSANT, DB4Objects, O2,

GEMSTONE, JASMINE, MATISSE, Objectivity/DB, Ozone.





Modelagem de Dados

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

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

“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

Modelo Conceitual de Dados (MCD)

O Modelo Conceitual representa e/ou descreve a realidade do ambienteobservado, constituindo-se em uma visão global dos principais dados erelacionamentos (estruturas de informação), independente das restrições deimplementação impostas por tecnologias, técnicas de implementação oudispositivos 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 etapado projeto de um sistema de aplicação em banco de dados, ele deve serutilizado para o nível de conversação, entendimento, transmissão, validação deconceitos, mapeamento do ambiente etc...

O objetivo do Modelo Conceitual é descrever as informações contidas em umarealidade, as quais irão estar armazenadas em um banco de dados. É umadescrição em alto nível (macro-definição), mas que tem a preocupação decaptar 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 osaspectos ligados à abordagem do banco de dados que será utilizado e tão poucose preocupa com as formas de acesso ou estruturas físicas implementadas porum SGBD (Sistema Gerenciador de Banco de Dados) específico.

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





Modelo Lógico de Dados (MLD)

Defini-se como modelo lógico de dados aquele em que os objetos, suascaracterísticas e relacionamentos têm a representação de acordo com as regrasde implementação e limitantes impostos por algum tipo de tecnologia.

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

O Modelo Lógico descreve as estruturas que estarão contidas no banco dedados, de acordo com as possibilidades permitidas pela abordagem, mas semconsiderar, 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.

Modelo Físico de Dados (MFD)

O Modelo Físico irá partir do Modelo Lógico e descreve as estruturas físicas dearmazenamento de dados, tais como: tamanho de campos, índices, tipo depreenchimento destes campos, nomenclaturas, etc. Será projetado de acordocom os requisitos de processamento e uso mais econômico dos recursoscomputacionais. Este modelo detalha o estudo dos métodos de acesso ao SGBD,para elaboração dos índices de cada informação colocada nos ModelosConceituais e Lógicos.

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

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

Modelo E-R

A 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 umapossí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 umreferencial definitivo para o processo de modelagem de dados. A abordagementidade-relacionamento é composta de uma técnica de diagramação e de umconjunto de conceitos que devem ser entendidos e respeitados. O modeloentidade-relacionamento é um modelo de dados conceitual de alto nível,cujos conceitos foram projetados para estar o mais próximo possível da visãoque o usuário tem dos dados, não se preocupando em representar como estesdados estarão realmente armazenados. O modelo ER é utilizado principalmentedurante o processo de projeto de banco de dados.





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

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

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

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





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

Entidade Atributo Relacionamento Cardinalidade

Entidade

Defini-se entidade como aquele objeto que existe no mundo real com umaidentificação distinta e um significado próprio, ou seja, é todo objeto concretoou abstrato que tem existência própria, quando considerado o âmbito de umnegó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). Estesobjetos estarão sendo percebidos como elementos individualizados, mas, aomesmo tempo, poderão ser enquadrados em um conjunto ou categoria emfunção de suas semelhanças, estes objetos neste processo de observação serãoas entidades, vejamos um exemplo:

Exemplo

Ao 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çasproduzidas.

• 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áriosconjuntos 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.


Cliente Fornecedor Pedido Aluno




Atributo

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

Descritivo:

É utilizado para descrever a entidade.

Identificador:

É utilizado para identificar unicamente uma linha da entidade.

Composto:

É um conjunto de tributos simples que pode ser referido como um únicoatributo.

Derivado:

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

Multivalorado:

Pode ser preenchido com muitos valores.


AtributoDescritivo

AtributoIdentificador

AtributoComposto

Agregado

agregado

Agregado

AtributoDerivado

Nome-atributo

AtributoMultivalorado




Exemplo de uma entidade e seus diferentes tipos de atributos:

Relacionamento

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

O relacionamento é representado por um losango.

Exemplo:

Assim, se desejarmos ter, conceitualmente, representado um ambienteobservado onde “Anderson é proprietário de um jipe amarelo”, podemos segui aseguinte 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:


Rua

Número

Bairro

Cidade

EndereçoIdade

AlunoData Nasc. RA

Data Nasc.Telefones

Aluno DisciplinaFreqüenta

Pessoa Carro




Relacionamento: Pessoa é proprietária de Carro

5. Representar o relacionamento

Grau do Relacionamento ou Cardinalidade

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

Quando questionamos se um homem poderia estar casado com mais de umamulher, 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 osmesmos 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 feitaem ambas as direções.

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


1,11,1Curso CoordenadorCoorden

a

mínimo

máximo

Pessoa Carro

É

Proprietária

Marido EsposaCasado

1 1




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.

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 umadada 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.


0,10,N

Vendedor RegiãoAtend

e

PD

Têxtil

Eletrônica

Douglas

Pedro

Ana

Campinas

Piracicaba

Sorocaba

Mário

CarlaJoão

Ana

Empresa FilialPossui

1 N




Relacionamento Muitos-para-Muitos (N:N)

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


Um fornecedor fornece zero ou muitos produtos.

Um produto é fornecido por zero ou muitos fornecedores.


W

X

Y

Z

A

B

C

D

E

0.N0.NFornecedor ProdutoForne

ce

Livro AutorEscrito

N N




Participação

Outra restrição muito importante é a participação. A participação define aexistência de uma entidade através do relacionamento, podendo ser parcialou total. Veja um exemplo.

A participação do empregado é parcial, pois nem todo empregado gerenciaum departamento, porém a participação do departamento nesterelacionamento é total, pois todo departamento precisa ser gerenciado porum empregado. Desta forma, todas as entidades do tipo DEPARTAMENTOprecisam participar do relacionamento, mas nem todas as entidade do tipoentidade EMPREGADO precisam participar do relacionamento.

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


RH

Projetos

Compras

LuizPaula

Pedro

Moacir

Fernanda

Maria

José

Empregado Gerencia

Departamento

Empregado DepartamentoGerenc

ia




1.1.1 Considerações sobre Entidades Fortes e Entidades Fracas

Alguns autores adotam, para fins de caracterização de uma entidade, umcritério que as classifica em fortes (regulares) ou fracas. Onde uma entidadefraca é 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ãoexistir.

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

• Dependência de existência.

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

• Dependência de identificador.

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

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 aentidade “Empregado” e para este empregado uma entidade “Dependente”, osdependentes de um empregado, poderiam ser classificados como entidadesfracas, pois os dependentes não poderiam existir sem um empregado não fossecadastrado. Em particular se algum empregado for excluído, todos os seusdependentes também devem ser excluídos.

Um conjunto de entidades fracas é identificado no modelo E-R pela linha duplausada no retângulo e no losango do relacionamento correspondente. Nodiagrama abaixo, o conjunto de entidades fracas pagamento é dependente doconjunto de entidades fortes Empréstimo pelo conjunto de relacionamento

pagamento_empréstimo. A figura também apresenta o uso de linhas duplaspara 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.





Relacionamentos Reflexivos (auto-relacionamento)

São os relacionamentos que ocorrem entre as ocorrências de uma mesmaentidade. Normalmente eles representam algum tipo de hierarquia.

Funcionário gerencia 0 ou muitos funcionários.

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

Extensões do Modelo Entidade x Relacionamento

O modelo de dados Entidade x Relacionamentos, como proposto por PeterChen, tem sido usado efetivamente para a comunicação do usuário final,

apresentando entidades e relacionamentos. Entretanto, quando usado paraintegrar diferentes modelos conceituais com diferentes usuários finais, ficaseveramente limitado até que se utilize um conceito de abstração de dadosdenominado generalização.

Relacionamentos entre Múltiplas Entidades

Até o momento analisamos apenas situações em que as entidades serelacionam sozinhas ou em pares, este é o principio da descoberta derelacionamentos, a analise de relacionamento em pares, no entanto umrelacionamento pode envolver mais de duas entidades, que podem sertrês, quatro, cinco ou uma quantidade indeterminada.


1,1

0,N

FuncionárioGerencia

Empréstimo PagamentoPagamento_E

mpréstimo

Número_empréstimo

Total

Data_Pagto

Número_pagamento

Total_pagto

Pagamento_empréstimo




Os relacionamentos entre múltiplas entidades expressam um fato emque todas as entidades ocorrem simultaneamente, ou seja, todas asocorrências do relacionamento possuem, sempre, ligações com todas asentidades envolvidas no relacionamento. Não é possível umrelacionamento triplo (Ternário), em um determinado momento,

transformar-se em duplo (Binário).

O diagrama abaixo representa uma situação de relacionamento queenvolve três entidades simultaneamente, a este tipo de relacionamentotriplo, 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.

Entidade associativa

Um relacionamento é uma associação entre entidades. Na modelagemER não foi prevista a possibilidade de associar dois relacionamentosentre si. Na pratica, quando estamos construindo um novo modelo ER oumodificando 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 seguinteforma. É necessário saber que medicamentos existem e quemedicamentos foram prescritos em cada consulta. Para saber quemedicamentos existem, cria-se uma nova entidade, Medicamento. Aquestão agora é: com que entidade existente deve estar relacionada anova 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,


Técnico Projetoatua

11

1

Notebook

NNMédico PacienteConsult

a




se Medicamento fosse relacionado à Paciente, faltaria a informação doMédico que prescreveu o medicamento. Assim, deseja-se relacionar aprescrição do Medicamento à consulta, ou seja, deseja-se relacionar umrelacionamento prescrição com da entidade (Medicamento) a umrelacionamento (Consulta), o que não está previsto na abordagem ER.

Para tal, foi criado um conceito especial, o de entidade associativa. Umaentidade associativa nada mais é que a redefinição de umrelacionamento, que passa a ser tratado como se fosse também umaentidade. 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 umaentidade, é possível associa-l através de relacionamentos a outrasentidades, conforme a figura apresentada acima.

Agregação

O termo agregação tem sido utilizado pelas técnicas de modelagem desistemas nos mais variados conceitos, porém o conceito lançado emModelagem de Dados refere-se à visão de um relacionamento como um

bloco, como alguma coisa que se relaciona com outra, Isso equivaledizer 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 fatosomente acontece após a existência do primeiro fato.


NNMédico PacienteConsult

a

Medicamento

Prescrição

N

N




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

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, poisquando definimos uma entidade, estamos com a visão de uma classegenérica de dados que pode estar incorporando, diversas outras classesde dados.

Generalização

Ao buscarmos as entidades presentes em um dado negócio, pode ser

realizado de modo bottom-up (baixo para cima), no qual podemosreconhecer vários conjuntos de entidades com atributos em comum,então, estes atributos comuns são sintetizados em um conjunto deentidades de alto nível.

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

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


N

N

N NCliente Quarto

Hospeda-se

Serviços

Utiliza




Então podemos ter como regra que ao encontrar um conjunto deentidades 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 umatributo qualificador para as ocorrências de cada uma.

Especialização

A especialização é justamente o inverso da generalização que é oprocesso de analise botton-up (de baixo para cima) tratado, aotratarmos da especialização, nos ocorre o processo inverso de análiseo processo top-down (de cima para baixo) que é o caso daespecialização, ou seja, um conjunto de entidades pode contersubgrupos (subtipos) de entidades que são de alguma forma,

diferentes de outras entidades do conjunto, continuando com oexemplo do digrama anterior, ao analisarmos nossa entidade a partirde médico, pode-se reconhecer subgrupos (subtipos) de médico,como Pediatra, Neurologista, Cardiologista, Clínico Geral , entreoutros.

Generalização X Especialização

Na pratica, a generalização é o inverso da especialização. Noprocesso 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


Médico

Pediatra Neurologista Clínico Geral Cardiologista




Bancos de Dados Relacionais

Definição

Foi criado por Edgar F. Codd na década de 70. A abordagem relacionalestá baseada no princípio de que as informações em uma base de dadospodem ser consideradas como relações matemáticas e que estãorepresentadas de maneira uniforme, através do uso de tabelasbidimensionais. Este princípio coloca os dados (entidades erelacionamentos) dirigidos para estruturas mais simples de armazenardados, 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 dadosrelacionais em relação aos ambientes tradicionais, pode serexemplificada da seguinte forma:

Em um ambiente tradicional, a função de acender um fósforo seriadescrita 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 queas 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 salade 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çãológica:

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





Tabela Relacional

Apresentamos abaixo uma relação de conceitos que definem uma tabelarelacional:

• 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 databela.• 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 nobanco 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 quea ordem das linhas é irrelevante.

Todas as colunas possuem um nome que significam algo.

A ordem das colunas não está desenvolvida para nenhuma finalidade declassificaçã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.





O conceito de Chave no Modelo Relacional

Chave Primária (Primary Key)

Em uma tabela existe uma coluna ou conjunto de colunas concatenados, cujovalor é único na tabela, ou seja, nunca se repete aquele valor em nenhumaoutra linha da tabela, e que identifica uma e somente uma única linha databela.

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

Na nossa tabela de funcionário, qual coluna ou conjunto de colunasconcatenadas 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 nosdizem nada.

Sobra neste caso a única coluna que não tem valores repetidos, que é amatrí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 deFuncionários.

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





Tabela de Consumos

Bebida Qtde ValorUnit.

LocalConsumo

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 colunasozinha poderia ser um identificador único da tabela.

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


LocalConsumo


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

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


LocalConsumo



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


LocalConsumo



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

pelo quarto 407.






LocalConsumo

Quarto DataConsumo

HoraConsumo

ValorTotal

Mate 1 1,50 Frigobar 407 21/01/200 16:30 1,50Mate 1 1,50 Restaurante 407 21/01/200 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 mesmonão ocorre com as duas linhas a seguir:


LocalConsumo

Quarto DataConsumo

HoraConsumo

ValorTotal

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

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

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


LocalConsumo

Quarto DataConsumo

HoraConsumo

ValorTotal

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

Café 1 0,80 Restaurante 203 18/01/200 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 mesmoquarto (hospedagem), no mesmo local, na mesma data e na mesma hora, poisse isso ocorrer, deveremos alterar a quantidade consumida ao invés deinserirmos duas linhas na tabela.

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 emuma das tabelas. Na outra tabela, este atributo irá caracterizar o quechamamos de chave estrangeira, propiciando assim, uma ligação lógica(relacionamento) entre as tabelas.

Exemplo:





Chave Candidata

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

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 tabelasque possuem mais de uma chave candidata.

Regras de Integridade do Modelo Relacional

Integridade de Identidade

A chave primária não pode conter um valor nulo (NULL). O NULL não é o valorzero nem o caractere branco, é simplesmente a não existência de conteúdonesse campo.

Integridade Referencial

Se uma determinada tabela A possui uma chave estrangeira, a qual é chaveprimá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 naqual ela é chave primária.

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


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

Departamento FuncionárioPossui

Chave primária Chave estrangeira




Características do Modelo Relacional

• Uma tabela é acessível por qualquer campo (atributo) independente seeste é declarado como chave ou não.

• O relacionamento entre as tabelas não existe fisicamente, pois esterelacionamento é 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.

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

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

Regras de Conversão

Existem regras precisas que não dão margem a erros, sendo que uma vezprojetado o diagrama ER, as tabelas que representam o ER num nível maisbaixo podem ser obtidas de forma clara.

Mapeamento de Entidades

Toda entidade torna-se uma tabela carregando todos os atributos definidos paraela.

Mapeando atributos

Cada atributo vira um campo da tabela criada. Os atributos identificadoresviram a chave primária da tabela.

Relacionamento 1:N (envolvendo entidades distintas)

A entidade (tabela) cuja cardinalidade é N recebe o atributo identificador daentidade cuja cardinalidade é 1 (chave estrangeira).

Exemplo:


DepartamentoCód_Depto Departamento

1 TI-Análise2 TI-Programação

3 TI-Operações4 RH5 TI-Gerência

FuncionárioNome Sexo Matrícula DeptoJoão Carlos M 373 3Carlos Brito M 872 2

Silvia 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




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

Relacionamento 1:1

As entidades (tabelas) envolvidas neste relacionamento carregarão oidentificador da outra (uma ou outra ou ambas) conforme a conveniência doprojeto (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.


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

1,1

0,N

Funcionário Gerencia

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 quepodemos ter funcionário que não chefiam nenhum departamento.


FuncionárioNome Sexo Matrícula Depto

Joã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




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

Relacionamento N:N

O relacionamento torna-se uma tabela carregando os atributos identificadoresdas entidades relacionadas e os atributos do relacionamento (quando houver).

Relacionamento Múltiplo

O relacionamento é mapeado em uma tabela, cuja chave primária é formadapela concatenação de todas as chaves estrangeiras.


DepartamentoCód_Depto Departamento

1 TI-Análise2 TI-Programação

3 TI-Operações4 RH5 TI-Gerência

EmpregadoNome Sexo Matrícula Chefia

DeptoTrabalhaDepto

João Carlos M 373 3 3

Carlos 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 Departamento Chefe

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

FuncionárioNome Sexo Matrícula Chefia

Depto

Trabalha

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

FuncionárioNome Sexo Matrícula

Joã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




Generalizações

Exemplo:

Dado um conjunto “funcionário”, existe uma variação para este, pois existemfuncioná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 acordocom o seu cargo.

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

Um elemento funcionário só pode ter um e somente um subconjunto. Asinformaçõ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 aoqual pertencem.


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




Normalização de Dados

Definição

O conceito de normalização foi introduzido por E. F. Codd em 1972.

Inicialmente Codd criou as três primeiras formas de normalização chamando-asde: primeira forma normal (1NF), segunda forma normal (2NF) e terceira formanormal (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 eexclusã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.


FuncionárioMatrícula Nome Função

4534 Soraia Mattos Ger6547 Breno Medeiros Eng7734 Gustavo Borges Eng1198 Ana Ferreira Eng3289 Telma Ribeiro Sec

Func_GerenteMat Aj Espec

4534 120 Eletr.

Func_SecretariaMat Língua Curso

4534 Inglês Secret.

Func_EngenheiroMat HR Ext Desp Ext Placa

4534 120 240 AHA8909

7734 ACA2356

3289 5 23 JOL1234




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

À 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 simcontrolá-las.

Primeira Forma Normal (1FN)

Uma relação está na primeira forma normal se os valores de seus atributos sãoatômicos (simples, indivisíveis) e monovalorados. Em outras palavras, FN1 nãopermite “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êmgrupos de repetição.

Exemplo:

Estrutura original:

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

Analisando a estrutura acima, observamos que existem várias mercadorias emuma única Venda, sendo, portanto elementos repetitivos que deverão serretirados.

Estrutura na primeira forma normal (1FN):

Arquivo de Vendas (Num Venda, Data emissão, Código do Cliente, NomeCliente, 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 daMercadoria, Quantidade vendida, Preço de venda e Total da venda destamercadoria)

Obs. Os campos sublinhados identificam as chaves das estruturas.

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

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

Segundo estrutura (Arquivo de Itens da Venda): Dados que compõem oselementos repetitivos da estrutura original, tendo como chave o campo chaveda estrutura original (Num Venda) e o campo chave da estrutura de repetição

(Código da Mercadoria).





Segunda Forma Normal (2FN) - Dependências Funcionais

Para uma tabela estar na segunda forma normal, além de estar na primeiraforma 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 apergunta: 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 docliente, 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 daMercadoria, Quantidade vendida, Preço de venda e Total da venda destamercadoria)

Estrutura na segunda forma normal (2FN):


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

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

Como resultado desta etapa, houve um desdobramento do arquivo de Itens daVenda (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 elementosoriginais, sendo excluídos os dados que são dependentes apenas do campoCódigo da Mercadoria.

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

- Terceira Forma Normal (3FN) - Dependências Transitivas

Para uma tabela estar na terceira forma normal, além de estar na segundaforma ela não deve conter dependências transitivas. Um jeito de verificar estanorma é refazer a leitura dos campos fazendo a pergunta: Este campo dependede outro que não seja a chave? Se ele depender temos uma dependênciatransitiva..





Exemplo:

Estrutura na segunda forma normal (2FN):


Arquivo de Itens da Venda (Num Venda, Código da Mercadoria, Quantidadevendida 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 Geralda Nota).

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


Arquivo de Clientes (Código do Cliente, Nome do cliente, Endereço do cliente eCGC 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 evitarinconsistência nos dados dos arquivos e economizar espaço por eliminar oarmazenamento freqüente e repetidas vezes destes dados. A cada venda feitapara o cliente, haverá o armazenamento destes dados e poderá ocorrerdivergência entre eles.

As estruturas alteradas foram pelos motivos, a saber:

Primeira estrutura (Arquivo de Vendas): Contém os elementos originais, sendoexcluí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ãoidentificados apenas pelo Código do Cliente, ou seja, independente da Venda, oNome, Endereço e CGC dos clientes serão constantes.

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





Quarta Forma Normal (4FN)

Na grande maioria dos casos, as entidades normalizadas até a 3FN são fáceis deentender, atualizar e de se recuperar dados. Mas às vezes podem surgirproblemas com relação a algum atributo não chave, que recebe valoresmúltiplos para um mesmo valor de chave. Esta nova dependência recebe o

nome de dependência multivalorada que existe somente se a entidade contiverno mínimo três atributos.

Uma entidade que esteja na 3FN também estará na 4FN, se ela não contivermais 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ês

1234 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 issoapresenta uma dependência multivalorada entre Código Funcionário eHabilidade e entre Código Funcionário e Idioma. Embora esteja na 3FN, aoconter 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 umadivisão da entidade original, em duas outras entidades, ambas herdando achave Código Funcionário e concatenado, em cada nova entidade, com osatributos 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





Quinta Forma Normal (5FN)

Um registro não pode ser reconstruído a partir de vários tipos de registrosmenores.

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 umaempresa, então ele vende esses produtos pela empresa.

Vendedor Empresa ProdutoSmith Ford CarroSmith Ford Caminhão

Smith GM CarroSmith GM CaminhãoJones Ford Carro

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

Vendedor EmpresaSmith FordSmith GM

Jones Ford


Empresa ProdutoFord CarroFord Caminhão

GM CarroGM Caminhão

Vendedor ProdutoSmith CarroSmith CaminhãoJones Carro




Problemas com a forma da tabela 1:

• Os fatos são registrados várias vezes. Por exemplo, o fato de que oSmith vende carros é registrado duas vezes. Se Smith parar de vendercarros, 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. Paragrandes 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 Carro

Brown 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 Brownnão vende caminhões.


Vendedor EmpresaSmith FordSmith GMJones Ford

Brown FordBrown GMBrown Toyota

Empresa ProdutoFord CarroFord CaminhãoGM Carro

GM CaminhãoToyota CarroToyota Ônibus

Vendedor ProdutoSmith CarroSmith CaminhãoJones Carro

Jones CaminhãoBrown CarroBrown Ônibus




• Brown é representante da Ford e Brown vende ônibus, mas a Ford nãofabrica ô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ãoPrática, Érica

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

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

KROENKE, DAVID M. - Banco de Dados: Fundamentos, projeto eimplementaçã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

ex modelagem good

Documents