Ex Modelagem Good

Administrao e Projeto de Banco de Dados
Administrao e Projeto de banco de dados
2010
Sistemas de Informao e Processamento de dados
Conceito de banco de dados. Modelagem conceitual de dados. Formas normais. Projeto lgico e fsico, segundo o modelo relacional. Linguagem de definio e manipulao de dados. O padro SQL. Concorrncia de transaes e mecanismos de manuteno de integridade, em sistemas de banco de dados. Views, Triggers, e Stored Procedures. Segurana e controle de acesso a informao.
Rudson Kiyoshi Souza Carvalho
Pgina 1
Contedo
Contedo.................................................................................2 Introduo e conceitos gerais.................................................5

Banco de dados........................................................................................5 Sistema de Banco de Dados......................................................................6 Principais componentes de um Sistema de Banco de Dados...........................6 Dados.....................................................................................................6 Hardware................................................................................................7 Software.................................................................................................7 Usurios..................................................................................................7 Usurios finais: .......................................................................................8 Administrador de Banco de Dados (DBA).....................................................8 Projetista de Banco de Dados (Administrador de Dados)................................8 Analistas de Sistemas e Programadores de Aplicaes ..................................8 Por que um Sistema de Banco de Dados?....................................................9 Vantagens tecnolgicas da utilizao de um Sistema de Banco de Dados.........9 Quando no Utilizar um SGBD..................................................................10 Arquitetura de sistemas de banco de dados...............................................11 Os trs nveis da arquitetura:...................................................................11 Independncia de Dados.........................................................................12 Sistema de Gerenciamento de Bancos de Dados (SGBD)........................13 Funes do SGBD...................................................................................13 Estrutura geral do SGBD..........................................................................13 Linguagens para Manipulao de Dados.................................................16 Modelos de Bancos de Dados...................................................................17 O Modelo Hierrquico..............................................................................17 O modelo de Rede..................................................................................18 O Modelo Relacional................................................................................19 O Modelo Orientado a Objetos..................................................................20
Modelagem de Dados.............................................................21
Modelo Conceitual de Dados (MCD)...........................................................21 Modelo Lgico de Dados (MLD).................................................................22 Modelo Fsico de Dados (MFD)..................................................................22 Modelo E-R.............................................................................................22 Entidade................................................................................................24 Atributo.................................................................................................25 Descritivo:.............................................................................................25 Identificador:.........................................................................................25 Composto:.............................................................................................25 Derivado:..............................................................................................25 Multivalorado:........................................................................................25 Relacionamento......................................................................................26 Grau do Relacionamento ou Cardinalidade.................................................27 Rudson Kiyoshi Souza Carvalho Pgina 2
Administrao e Projeto de Banco de Dados Relacionamento Um-para-Um (1:1)..........................................................27 Relacionamento Um-para-Muitos (1:N)......................................................28 Relacionamento Muitos-para-Muitos (N:N).................................................29 Participao...........................................................................................30 Relacionamentos Reflexivos (auto-relacionamento).....................................32 Extenses do Modelo Entidade x Relacionamento..................................32 Relacionamentos entre Mltiplas Entidades................................................32 Entidade associativa................................................................................33 Agregao.............................................................................................34 Generalizao (Supertipos) e Especializao (Subtipos)...............................35 Generalizao........................................................................................35 Especializao........................................................................................36 Generalizao X Especializao.................................................................36
Bancos de Dados Relacionais.................................................37

Definio................................................................................................37 Tabela Relacional...................................................................................38 O conceito de Chave no Modelo Relacional.............................................39 Chave Primria (Primary Key)..................................................................39 Chave Estrangeira (Foreign Key)..............................................................41 Chave Candidata....................................................................................42 Chave Secundria (Secundary Key)..........................................................42 Regras de Integridade do Modelo Relacional..........................................42 Integridade de Identidade.......................................................................42 Integridade Referencial...........................................................................42 Caractersticas do Modelo Relacional.....................................................43
Derivao do Modelo Entidade x Relacionamento para o Modelo Lgico Relacional.......................................................43

Regras de Converso..............................................................................43 Mapeamento de Entidades.......................................................................43 Mapeando atributos................................................................................43 Relacionamento 1:N (envolvendo entidades distintas).................................43 Relacionamento 1:N (envolvendo auto-relacionamento)..............................44 Relacionamento 1:1................................................................................44 Relacionamento N:N...............................................................................46 Relacionamento Mltiplo..........................................................................46 Generalizaes.......................................................................................47
Normalizao de Dados........................................................49
Definio................................................................................................49 Primeira Forma Normal (1FN)...................................................................50 Segunda Forma Normal (2FN) - Dependncias Funcionais............................51 - Terceira Forma Normal (3FN) - Dependncias Transitivas..........................51 Quarta Forma Normal (4FN).....................................................................53 Quinta Forma Normal (5FN).....................................................................54 Bibliografia............................................................................................57 Rudson Kiyoshi Souza Carvalho Pgina 3
Pgina 4
Introduo e conceitos gerais

Antes de definir banco de dados, vamos definir alguns conceitos bsicos ligados ao mesmo, como dado, informao e conhecimento. Dado qualquer elemento identificado em sua forma bruta que, por si s, no conduz a uma compreenso de determinado fato ou situao (Oliveira, 2005) Informao o dado trabalhado que agrupado de maneira lgica permite aos usurios desta informao tomar decises. (Oliveira, 2005) Conhecimento a informao associada em mltiplos 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 informao.
Figura 1 Relao entre dado, informao 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 significado implcito. Porm, o significado do termo banco de dados mais restrito que simplesmente a definio dada acima. Um banco de dados possui as seguintes propriedades: um banco de dados uma coleo lgica coerente de dados com um significado inerente; uma disposio desordenada dos dados no pode ser referenciada como um banco de dados; um banco de dados projetado, construdo e preenchido com dados para um propsito especfico; um banco de dados possui um conjunto pr definido de usurios e aplicaes;
Pgina 5
Administrao e Projeto de Banco de Dados um banco de dados representa algum aspecto do mundo real, o qual chamado de mini-mundo ; qualquer alterao efetuada no mini-mundo automaticamente refletida no banco de dados. Um banco de dados pode ser criado e mantido por um conjunto de aplicaes desenvolvidas especialmente para esta tarefa ou por um Sistema Gerenciador de Banco de Dados (SGBD). Um SGBD permite aos usurios criarem e manipularem bancos de dados de propsito gerais. O conjunto formado por um banco de dados mais as aplicaes 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 um sistema computadorizado de manuteno de registros. O banco de dados, por si s, pode ser considerado como o equivalente eletrnico de um armrio de arquivamento, ou seja, ele um repositrio ou recipiente para uma coleo de arquivos de dados computadorizados, de modo geral a finalidade de um banco de dados armazenar informaes e permitir que os usurios busquem e atualizem essas informaes quando forem requisitadas. As informaes em questo podem ser qualquer coisa que tenha um significado ao individuo ou organizao a que o sistema deve servir. Os usurios de um sistema podem realizar (ou melhor, solicitar que o sistema realize) diversas operaes 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
Principais componentes de um Sistema de Banco de Dados Um sistema de banco de dados envolve 4 componentes principais: 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 requisio explcita ao mesmo. Isso difere de outros tipos de dados, como, por exemplo, dados de entrada, dados de sada, filas de trabalho, instrues SQL e quaisquer outros que possuam natureza transitria. Os dados em um compartilhados sistema de banco de dados so integrados e Dados Hardware Software Usurios
Pgina 6
Administrao e Projeto de Banco de Dados Por integrado, queremos dizer que o banco de dados pode ser considerado como uma unificao de vrios arquivos que, de outro modo, seriam distintos, com a eliminao de qualquer redundncia parcial ou total entre esses arquivos. Por compartilhado, queremos dizer que o banco de dados pode ser compartilhado entre diferentes usurios, no sentido de que diferentes usurios podem ter acesso aos mesmos dados, possivelmente ao mesmo tempo (acesso concorrente). Tambm devemos fazer uma diferenciao entre dado e informao. O dado aquilo que realmente armazenado no banco de dados, enquanto a informao refere-se ao significado desses dados para determinado usurio. 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 informao que em 20/12/1990 esse cliente estava com 20 anos. Hardware Os componentes de hardware do sistema de banco de dados consistem em: Volumes de armazenamento secundrio normalmente discos magnticos -, que so usados para manter os dados armazenados, juntamente com os dispositivos de E/S (entrada/sada) associados (unidades de disco etc), controladores de dispositivos, canais de E/S e assim por diante. Processador(es) de hardware e memria principal associada, que so usados para dar suporte execuo do software do sistema de banco de dados.
Software Entre o banco de dados fsico ou seja, os dados fisicamente armazenados e os usurios do sistema existe uma camada de software conhecida como gerenciador de banco de dados, ou mais freqentemente conhecido SGBD Sistema Gerenciador de Banco de dados. O SGBD ser responsvel por tratar todas as requisies citadas anteriormente como acrescentar novos arquivos ao banco de dados ou inserir dados em arquivos existentes etc.. Usurios Os usurios (finais) acessam o banco de dados interativamente atravs de alguma aplicao ou interface on-line que na maioria das vezes podem ser oferecidas pelo fornecedor do SGBD estas aplicaes so internas (built-in), e no escrita pelos usurios, a maior parte dos sistemas possui pelo menos uma aplicao built-in, chamada de processador de linguagem de consulta, por meio do qual o usurio pode emitir requisies ao banco de dados. Consideremos de forma geral quatro classes de usurios que interagem com o banco de dados:
Pgina 7
Administrao e Projeto de Banco de Dados Usurios finais: Existem basicamente trs categorias de usurios finais que so os usurios finais do banco de dados, fazendo consultas, atualizaes e gerando documentos: Usurios casuais: acessam o banco de dados casualmente, mas que podem necessitar de diferentes informaes a cada acesso; utilizam sofisticadas linguagens de consulta para especificar suas necessidades; Usurios novatos ou paramtricos: utilizam pores pr-definidas do banco de dados, utilizando consultas pr-estabelecidas que foram exaustivamente testadas; Usurios sofisticados ou de alto nvel: so usurios que esto familiarizados 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 primrio o banco de dados por si s e o recurso secundrio o SGBD e os softwares relacionados. A administrao destes recursos cabe ao Administrador de Banco de Dados, o qual responsvel pela autorizao de acesso ao banco de dados e pela coordenao e monitorao de seu uso. So tarefas do DBA: de Definio da estrutura de armazenamento e a estratgia (ou mtodo) acesso. Concesso de autorizao para acesso a dados. Definio de controles de integridade. Definio de estratgias para cpia de segurana e recuperao. Monitoramento do desempenho. Execuo de rotinas de desempenho. Modificao da organizao fsica.
Projetista de Banco de Dados (Administrador de Dados) O Projetista de Banco de Dados responsvel pela identificao 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 aps a construo do banco de dados. funo do projetista tambm avaliar as necessidades de cada grupo de usurios para definir as vises que sero necessrias, integrando-as, fazendo com que o banco de dados seja capaz de atender a todas as necessidades dos usurios. So tarefas do AD: Definio e atualizao do esquema do banco de dados. Analistas de Sistemas e Programadores de Aplicaes Os analistas determinam os requisitos dos usurios finais e desenvolvem especificaes para transaes que atendam estes requisitos, e os programadores so os responsveis pelo desenvolvimento de aplicaes em linguagens como Java, Cobol, C#, C++, VB.net e etc. que fazem chamadas ou requisies ao SGBD atravs de instrues SQL Rudson Kiyoshi Souza Carvalho Pgina 8
Por que um Sistema de Banco de Dados? As vantagens de um sistema de banco de dados em relao aos mtodos tradicionais, baseados em papel so muitas, como por exemplo: Densidade: No h possivelmente volumosos. a necessidade de arquivos de papel,
Velocidade: A mquina pode obter e atualizar dados com uma velocidade muito maior do que o ser humano. Atualidade: Informaes precisas e atualizadas esto disponveis a qualquer momento sob consulta. Proteo: Os dados podem ser bem protegidos contra a perda no intencional e acesso ilegal. Vantagens tecnolgicas da utilizao de um Sistema de Banco de Dados Controle de Redundncia
A redundncia consiste no armazenamento de uma mesma informao em locais diferentes, provocando inconsistncias. Em um Banco de Dados as informaes s se encontram armazenadas em um nico local, no existindo duplicao descontrolada dos dados. Compartilhamento de Dados
Um banco de dados multiusurio deve permitir que mltiplos usurios acessem o banco de dados ao mesmo tempo. Este fator essencial para que mltiplas aplicaes integradas possam acessar o banco. O banco de dados multiusurio deve manter o controle de concorrncia para assegurar que o resultado de atualizaes seja correto. Um banco de dados multiusurio deve fornecer recursos para a construo de mltiplas vises. Restrio a Acesso no Autorizado
O banco de dados deve dispor de recursos que possibilitem selecionar a autoridade de cada usurio. Assim um usurio poder realizar qualquer tipo de acesso, outros podero ler alguns dados e atualizar outros e outros ainda podero somente acessar um conjunto restrito de dados para escrita e leitura. Tolerncia a Falhas
Um banco de dados deve fornecer recursos para recuperao de falhas tanto de software quanto de hardware. Integridade
Um banco de dados dever impedir que aplicaes ou acessos pelas interfaces possam comprometer a integridade dos dados.
Pgina 9
Administrao e Projeto de Banco de Dados Suporte a transaes
Uma transao uma unidade lgica de trabalho (mais precisamente, uma unidade lgica de trabalho de banco de dados), em geral envolvendo diversas operaes de banco de dados, onde uma operao s pode ser validada pelo banco de dados se todas as demais operaes da transao tambm o forem. Exemplo: Transao bancria de transferncia de dinheiro. A transao s pode ser validada se as operaes de dbito em uma conta origem e crdito em uma conta destino forem validados. Quando no Utilizar um SGBD Em algumas situaes, o uso de um SGBD pode representar uma carga desnecessria aos custos quando comparado abordagem processamento tradicional de arquivos como, por exemplo: Alto investimento adicionais; inicial na compra de software e hardware
Generalidade que um SGBD fornece na definio e processamento de dados; Sobrecarga na proviso de controle de segurana, controle de concorrncia, recuperao e integrao de funes. Problemas adicionais podem surgir caso os projetistas de banco de dados ou os administradores de banco de dados no elaborem os projetos corretamente ou se as aplicaes no so implementadas de forma apropriada. Se o DBA no administrar o banco de dados de forma apropriada, tanto a segurana quanto a integridade dos sistemas podem ser comprometidas. A sobrecarga causada pelo uso de um SGBD e a m administrao justificam a utilizao da abordagem processamento tradicional de arquivos em casos como: O banco de dados e as aplicaes so simples, bem definidas e no se espera mudanas no projeto; A necessidade de processamento em tempo real de certas aplicaes, que so terrivelmente prejudicadas pela sobrecarga causada pelo uso de um SGBD; No haver mltiplo acesso ao banco de dados.
Pgina 10
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 aplicaes de usurios da base de dados fsica. Nessa arquitetura a base de dados pode ser definida em trs nveis: Nvel Externo, Nvel Conceitual e Nvel Interno ou Fsico. Os trs nveis da arquitetura: O nvel externo ou viso (tambm conhecido como nvel lgico de usurio) o mais prximo dos usurios, ou seja, aquele que se ocupa de como os dados so vistos por usurios individuais, como os dados esto organizados para formar a informao para cada usurio. O nvel externo possui esquemas externos ou vises e no depende do sistema gerenciador de banco de dados. Cada esquema descreve a viso da informao de um grupo de usurios. Cada viso descreve, tipicamente, parte da base de dados que um particular grupo de usurios est interessado e esconde o resto da base de dados do mesmo. O nvel conceitual (tambm conhecido como nvel lgico de comunidade, ou as vezes apenas como nvel lgico, sem qualificao) possu um esquema conceitual que representa a estrutura da base de dados que o produto da normalizao. uma viso mais apropriada para os projetistas onde todos os conjuntos de dados do nvel externo esto quebrados em pedaos lgicos, fundidos para reduzir repetio, e estruturados para eliminar dependncias. O esquema conceitual uma descrio global da base de dados, que omite detalhes da estrutura de armazenamento fsico e se concentra na descrio de entidades, tipos de dados, relacionamento e restries (Diagrama de Entidade e Relacionamento). O nvel Interno ou Fsico (tambm conhecido como nvel de armazenamento) o mais prximo do meio de armazenamento fsico, ou seja, aquele que se ocupa do modo como os dados, ou melhor, registros e arquivos so fisicamente armazenados dentro da base de dados e depende fortemente do SGBD selecionado. uma viso mais apropriada aos programadores de base de dados. Todos os conjuntos de dados do nvel fsico esto organizados para aperfeioar a velocidade de execuo, maximizar a disponibilidade dos dados, e manter os dados seguros.
Pgina 11
Figura 2 Os trs nveis da arquitetura.
Analisando a imagem podemos observar que o nvel externo se preocupa com as percepes dos usurios individuais, enquanto o nvel conceitual est preocupado com uma percepo da comunidade de usurios. Na maioria dos casos alguns usurios no tero acesso a toda informao do banco de dados, mas somente acessaro algumas partes das informaes contidas no mesmo; assim, haver muitas vises externas distintas, cada qual consistindo em uma representao abstrata de alguma parte da informao contida no banco de dados, e haver uma viso conceitual, consistindo em uma representao igualmente abstrata do banco de dados em sua totalidade. Do mesmo modo haver uma viso interna, representando o modo como os dados esto armazenados internamente. Independncia de Dados A independncia de dados pode ser definida como a capacidade de se alterar um esquema em um nvel em um banco de dados sem ter que alterar um nvel superior (figura anterior). Existem dois tipos de independncia de dados: Independncia de dados lgica: a capacidade de alterar o esquema conceitual sem ter que alterar o esquema externo ou as aplicaes do usurio, ou seja, podemos alterar o esquema conceitual sem a necessidade de reescrever os programas aplicativos. Algumas vezes necessrio alterar a estrutura lgica do banco de dados como por exemplo adicionando alguma nova entidade (tabela) ao banco. Independncia de dados fsica: a capacidade de alterar o esquema interno sem ter que alterar o esquema conceitual, o esquema externo ou as aplicaes do usurio, ou seja, podemos alterar o esquema fsico sem Pgina 12
Administrao e Projeto de Banco de Dados a necessidade de reescrever os programas aplicativos. Algumas vezes so necessrias modificaes no nvel fsico para melhorar o desempenho.
Sistema de Gerenciamento de Bancos de Dados (SGBD)

Um sistema gerenciador de banco de dados (SGBD) responsvel por armazenar dados de forma confivel e permitir fcil recuperao e atualizao 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 seqncia abaixo ilustra o papel do sistema de gerncia de banco de dados, de forma conceitual: 1. O usurio emite uma solicitao de acesso. 2. O SGBD intercepta a solicitao e a analisa. 3. O SGBD inspeciona os esquemas externos (ou sub-esquemas) relacionados quele usurio, os mapeamentos entre os trs nveis, e a definio da estrutura de armazenamento. 4. O SGBD realiza as operaes solicitadas no banco de dados armazenado. Exemplos de SGBD: Oracle, Microsoft SQL Server. IBM DB2, SyBase, Paradox, Progress, MySql, Microsoft Access etc. Funes do SGBD Interao com o sistema de arquivos do sistema operacional. Cumprimento da integridade. Cumprimento da segurana. Cpias de segurana (backup) e recuperao. Controle de concorrncia. Otimizao e execuo dos comandos DML. Dicionrio de Dados. Desempenho.
Estrutura geral do SGBD Um sistema de banco de dados dividido em mdulos que tratam de cada uma das responsabilidades do sistema geral. Na maioria dos casos, o sistema operacional do computador fornece apenas os servios mais bsicos e o sistema de banco de dados precisa ser construdo sobre essa base. Portanto, o projeto do sistema de banco de dados precisa incluir consideraes 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 alocao do espao na armazenagem do disco e as estruturas de dados usadas para representar a informao armazenada no disco. Gerenciador do banco de dados, que fornece a interface entre os dados de baixo nvel armazenados no disco e os programas aplicativos e de consulta submetidos ao sistema. Pgina 13
Administrao e Projeto de Banco de Dados Processador de consultas, que traduz os comandos numa linguagem de consulta para instrues de baixo nvel que o gerenciador do banco de dados pode interpretar. Alm disso, o processador de consultas tenta transformar uma requisio do usurio em uma forma compatvel e mais eficiente com respeito ao banco de dados, encontrando uma boa estratgia 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 cdigo 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 so requeridas como parte da implementao do sistema fsico, incluindo: Arquivos de dados, que armazenam o banco de dados propriamente dito. Dicionrio de dados, que armazena metadados sobre a estrutura do banco de dados. O dicionrio de dados usado com freqncia. Assim, deve-se dar grande nfase no desenvolvimento de um bom projeto e implementao eficiente do dicionrio. ndices, que fornecem acesso rpido aos itens de dados guardando determinados valores.
Estrutura bsica de um sistema gerenciador de Banco de dados
Figura 3 Estrutura bsica de um SGBD
Pgina 14
Administrao e Projeto de Banco de Dados Viso expandida da arquitetura do sistema de banco de dados
Figura 4 Estrutura expandida de um SGBD
Pgina 15
Linguagens para Manipulao de Dados

Quando tratamos de banco de dados, e desejamos criar uma estrutura lgica para armazenamento e organizao destes dados e realizar consultas, alteraes, restries de acesso, definies de esquemas e etc, fazemos uso de uma linguagem que nos auxilie e facilite realizar esta tarefa. As Linguagens para Manipulao de Dados so divididas em trs grupos de comandos: DDL (Data Definition Language - Linguagem de Definio de Dados) Para a criao dos objetos do banco de dados (tabelas, ndices, relacionamentos, vises etc) utilizamos a linguagem DDL (Data Definition Language - Linguagem de Definio de Dados). O SGBD possui um compilador DDL que permite a execuo das declaraes para identificar as descries dos esquemas e para armazen-las no catlogo do SGBD. DML (Data Manipulation Language - Linguagem de Manipulao de Dados) Uma vez que o banco de dados esteja criado, usa-se uma linguagem para fazer a manipulao dos dados (ler, inserir, alterar e excluir), a DML (Data Manipulation Language - Linguagem de Manipulao de Dados). DCL (Data Control Language) Linguagem de Controle de Dados Utilizada para tratar as permisses do banco de dados como a concesso (GRANT) ou revogao (REVOKE) de privilgios no banco de dados.
Pgina 16
Modelos de Bancos de Dados

Existem diversos modelos de banco de dados, e cada modelo tem suas caractersticas de manipulao e armazenamento dos dados, dentre estes modelos vamos conhecer os quatro principais e mais comuns modelos encontrados no mercado, so eles: o modelo hierrquico, em rede, relacional e orientado a objetos. Para explicarmos cada modelo, iremos utilizar as informaes da tabela abaixo: Nome Joo Ana Pedro Municpio SBC SP Osasco Estado SP SP SP Conta A102 A101 A202 A305 Saldo 400,00 500,00 900,00 350,00
O Modelo Hierrquico O modelo hierrquico uma coleo de registros conectados uns aos outros por meio de links. Um registro , em muitos aspectos, similar a uma entidade do modelo entidade x relacionamento que veremos mais a frente. Cada registro uma coleo de campos (atributos), cada qual contendo somente um valor. Um link uma associao entre exatamente dois registros. Portanto, um link pode ser visto como uma forma restrita (binria) de relacionamento no sentido do modelo entidade x relacionamento. Este modelo utiliza rvores para a representao lgica dos dados. Esta rvore esta composta de uns elementos chamados ns. O nvel mais alto da rvore denomina-se raiz. Cada n representa um registro com seus correspondentes campos. A representao grfica deste modelo se realiza mediante a criao de uma rvore invertida, os diferentes nveis ficam unidos mediante relaes.
Figura 5 Banco de Dados Modelo Hierrquico Neste modelo s se podem representar relaes 1:M (uma para muitos), por isso apresenta vrios inconvenientes como: No se admitem relaes N:M (muitos para muitos) Um segmento filho no pode ter mais de um pai. No se permitem mais de uma relao entre dois segmentos. Para acessar a qualquer segmento necessrio comear pelo segmento raiz A rvore se deve percorrer na ordem designada. Rudson Kiyoshi Souza Carvalho Pgina 17
Administrao e Projeto de Banco de Dados Exemplos de banco de dados Hierrquico: IBMs IMS (DL/1, IMS DB, IMS DC), SYSTEM 2000 O modelo de Rede Um banco de dados de rede uma coleo de registros conectados uns aos outros por meio de links. Um registro , em muitos aspectos, similar a uma entidade do modelo entidade x relacionamento. Cada registro uma coleo de campos (atributos), cada qual contendo somente um valor. Um link uma associao entre exatamente dois registros. Portanto, um link pode ser visto como uma forma restrita (binria) de relacionamento no sentido do modelo entidade x relacionamento. Nesta estrutura qualquer componente pode se relacionar com qualquer outro. Diferentemente do modelo hierrquico, neste modelo, um filho pode ter vrios pais.
Figura 6 Banco de Dados Modelo de Rede Os conceitos bsicos no modelo em rede so: 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 relaes N:M (muitos para muitos) Exemplo de banco de dados de Rede: IDMS (Cullinet), DMS 1100 (Sperry), TOTAL (Cincom Systems)
Pgina 18
O Modelo Relacional O Modelo Relacional de banco de dados o modelo no qual iremos nos aprofundar nesse curso, por ser um modelo de fcil entendimento e o mais utilizado atualmente. Ele representa os dados por meio de conceitos matemticos da teoria dos conjuntos. Dirigido, este modelo foi proposto pelo pesquisador Edgar Ted Frank Codd em jun/1970, este modelo melhora a viso 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 relao entre duas tabelas feita atravs de colunas em comum (chave primria e chave estrangeira).
Figura 7 Banco de Dados Relacional Algumas de suas principais caractersticas so: Pode ser entendido e usado por qualquer usurio. Permite ampliar o esquema conceitual sem modificar as aplicaes de gerenciamento. Os usurios no necessitam saber onde se encontram os dados fisicamente. O elemento principal deste modelo a relao 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)
Pgina 19
O Modelo Orientado a Objetos basicamente um sistema em que a unidade de armazenamento o objeto, com o mesmo conceito das linguagens de programao orientadas a objetos. A diferena fundamental a persistncia dos objetos, ou seja, os objetos continuam a existir mesmo aps o encerramento do programa. Atravs das construes orientadas a objeto, os programadores podem esconder os detalhes da implementao de seus mdulos, compartilhar a referncia a objetos e expandir seus sistemas atravs de mdulos existentes. A funcionalidade de banco de dados necessria para assegurar o compartilhamento concomitante e a continuidade das informaes nas aplicaes. Atravs dos bancos de dados os programadores podem obter o estado em que os objetos se encontram, e estar atualizados entre vrias solicitaes do programa, e vrios usurios podem ao mesmo tempo compartilhar a mesma informao. O banco de dados orientado a objeto combina os benefcios e conceitos da orientao a objetos com a funcionalidade dos bancos de dados.
Figura 8 Banco de Dados Orientado a Objetos Algumas de suas principais caractersticas so: Os dados so armazenados como objetos
Os objetos so organizados numa hierarquia de tipos, e subtipos que recebem as caractersticas de seus supertipos. O acesso aos dados pode ser rpido porque as junes geralmente no so necessrias. Exemplo de banco de dados OO: CACH, VERSANT, DB4Objects, O2, GEMSTONE, JASMINE, MATISSE, Objectivity/DB, Ozone.
Pgina 20
Modelagem de Dados
Para comearmos a tratar de modelagem de dados, vamos primeiramente definir modelo. Modelo: a representao 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 imaginrio. Paulo Cougo O processo de modelagem de um banco de dados dividido em trs etapas: Modelo Conceitual Modelo Lgico Modelo Fsico
Modelo Conceitual de Dados (MCD) O Modelo Conceitual representa e/ou descreve a realidade do ambiente observado, constituindo-se em uma viso global dos principais dados e relacionamentos (estruturas de informao), independente das restries de implementao impostas por tecnologias, tcnicas de implementao ou dispositivos fsicos, ou seja, na etapa de elaborao do modelo conceitual, pouco importa se o sistema escolhido ser um SGBD Relacional, de Rede ou Hierrquico. Quando se fala em Modelo Conceitual, estamos nos referindo a primeira etapa do projeto de um sistema de aplicao em banco de dados, ele deve ser utilizado para o nvel de conversao, entendimento, transmisso, validao de conceitos, mapeamento do ambiente etc... O objetivo do Modelo Conceitual descrever as informaes contidas em uma realidade, as quais iro estar armazenadas em um banco de dados. uma descrio em alto nvel (macro-definio), mas que tem a preocupao de captar e retratar toda a realidade de uma organizao, setor, repartio, departamento, negcio etc. Como dizemos no inicio deste tpico, o Modelo Conceitual no retrata os aspectos ligados abordagem do banco de dados que ser utilizado e to pouco se preocupa com as formas de acesso ou estruturas fsicas implementadas por um SGBD (Sistema Gerenciador de Banco de Dados) especfico. O resultado de um Modelo Conceitual um esquema que representa a realidade das informaes existentes, assim como as estruturas de dados que representam estas informaes.
Pgina 21
Administrao e Projeto de Banco de Dados Modelo Lgico de Dados (MLD) Defini-se como modelo lgico de dados aquele em que os objetos, suas caractersticas e relacionamentos tm a representao de acordo com as regras de implementao e limitantes impostos por algum tipo de tecnologia. O Modelo Lgico tem o seu incio a partir do Modelo Conceitual, levando em considerao a abordagem de rede, hierrquica, 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, normalizao, ponteiros, headers, integridade referencial, entre outros. Estas so preocupaes e necessidades somente relevantes ao Modelo Lgico, jamais devem ser levadas ao Modelo conceitual. O Modelo Lgico descreve as estruturas que estaro contidas no banco de dados, de acordo com as possibilidades permitidas pela abordagem, mas sem considerar, ainda, nenhuma caracterstica especfica de um Sistema Gerenciador de Banco de Dados (SGBD), resultando em um esquema lgico de dados sob a tica de uma das abordagens citadas. Modelo Fsico de Dados (MFD) O Modelo Fsico ir partir do Modelo Lgico e descreve as estruturas fsicas 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 econmico dos recursos computacionais. Este modelo detalha o estudo dos mtodos de acesso ao SGBD, para elaborao dos ndices de cada informao colocada nos Modelos Conceituais e Lgicos. Cada empresa fornecedora do SGBD poder definir um diferente modo de implementao fsica das caractersticas e recursos necessrios para o armazenamento e manipulao das estruturas de dados Esta a etapa final do projeto de Banco de Dados, na qual ser utilizada a Linguagem de Definio de Dados do SGBD (DDL), para a criao fsica do banco de dados proposto.
Modelo E-R
A abordagem Entidade-Relacionamento Em maro de 1976, Peter P. Chen publicou um trabalho intitulado The EntityRelationship Model: Toward the unified view of data, no qual definia uma possvel abordagem para o processo de modelagem dos dados. Esse trabalho, aps sua divulgao e ampla aceitao, passou a ser considerado como um referencial definitivo para o processo de modelagem de dados. A abordagem entidade-relacionamento composta de uma tcnica de diagramao e de um conjunto de conceitos que devem ser entendidos e respeitados. O modelo entidade-relacionamento um modelo de dados conceitual de alto nvel, cujos conceitos foram projetados para estar o mais prximo possvel da viso que o usurio tem dos dados, no se preocupando em representar como estes dados estaro realmente armazenados. O modelo ER utilizado principalmente durante o processo de projeto de banco de dados. Rudson Kiyoshi Souza Carvalho Pgina 22
Administrao e Projeto de Banco de Dados O modelo ER utiliza, basicamente, os retngulos para representar as entidades, losangos para representar os relacionamentos, elipses (bales) 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 indicam participao total de uma entidade em um conjunto de relacionamentos. O diagrama ER fornece uma viso lgica do banco de dados, fornecendo um conceito mais generalizado de como esto estruturados os dados de um sistema. Os objetos que compem o diagrama ER esto listados a seguir, na figura abaixo:
Pgina 23
Administrao e Projeto de Banco de Dados Os principais conceitos utilizados para a construo do modelo ER so: Entidade Defini-se entidade como aquele objeto que existe no mundo real com uma identificao distinta e um significado prprio, ou seja, todo objeto concreto ou abstrato que tem existncia prpria, quando considerado o mbito de um negcio. So coisas sobre as quais desejamos arquivar informaes. So as coisas que existem no negcio, ou ainda, descrevem o negcio em si. A entidade representada por um retngulo, conforme as figuras abaixo: Entidade Atributo Relacionamento Cardinalidade
Cliente
Fornecedor
Pedido
Aluno
Em um universo observado, estaremos reconhecendo objetos (coisas). Estes objetos estaro sendo percebidos como elementos individualizados, mas, ao mesmo tempo, podero ser enquadrados em um conjunto ou categoria em funo de suas semelhanas, estes objetos neste processo de observao sero as entidades, vejamos um exemplo: Exemplo Ao observarmos um ambiente de produo de uma fbrica, nos defrontaremos com: Maquinas de produo de peas. Funcionrios operadores dessas mquinas. Conjunto de ferramentas para operar e dar manuteno as mquinas. Procedimentos de operaes a serem realizadas.
Procedimentos de medies e verificao da qualidade das peas produzidas. Mquinas recuperadoras de peas. Funcionrios responsveis pela verificao da qualidade das peas. Peas produzidas nos mais diversos formatos.
Dentre esses elementos observados, poderemos perceber a existncia de vrios conjuntos distintos de elementos (entidades), entre eles: Mquina que representa todas as mquinas observadas. Funcionrio que representa todos os funcionrios. Ferramenta que representa todas as ferramentas. Peas que representar todos os tipos de peas produzidas.
Pgina 24
Administrao e Projeto de Banco de Dados Atributo uma informao 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. Descritivo: utilizado para descrever a entidade.
Atributo
Descritivo Identificador:
utilizado para identificar unicamente uma linha da entidade.
Identificador Composto:
Atributo
um conjunto de tributos simples que pode ser referido como um nico atributo.
Composto
Atributo
Agregad o agregad o Agregad o
Derivado: Pode ter um valor que derivvel de valores de outros atributos.
Derivado Multivalorado: Pode ser preenchido com muitos valores.
Atributo
Multivalorado
NomeAtributo atributo
Pgina 25
Administrao e Projeto de Banco de Dados Exemplo de uma entidade e seus diferentes tipos de atributos:
Data Nasc.
Aluno
RA
Rua Idade
Endereo
Nmero Bairro
Data Nasc. Telefones
Cidade
Relacionamento a ligao entre duas ou mais entidades. Ao observarmos os objetos e reconhec-los, estaremos quase que imediatamente, reconhecendo as relaes existentes entre eles. Muitas vezes a prpria observao de um relacionamento ser o ponto de partida para a identificao dos objetos que dele participam. O que estabelecer associaes vlidas ou no ser simplesmente o grau de fidelidade e completeza que consigamos atingir durante o processo de modelagem. O relacionamento representado por um losango. Exemplo:
Aluno
Freqen ta
Disciplina
Assim, se desejarmos ter, conceitualmente, representado um ambiente observado onde Anderson proprietrio de um jipe amarelo, podemos segui a seguinte estratgia: 1. Identificar os objetos envolvidos (entidades): Pessoa (Anderson) Carro (Jipe Amarelo)
2. Caracterizar os objetos (atributos): Pessoa (nome, data nascimento, nmero CPF e etc.) Carro (marca, cor, ano de fabricao, modelo etc.)
3. Representar os objetos:
Pessoa Carro
4. Identificar o relacionamento entre os objetos: Rudson Kiyoshi Souza Carvalho Pgina 26
Administrao e Projeto de Banco de Dados Relacionamento: Pessoa proprietria de Carro
5. Representar o relacionamento
Proprietri a
Pessoa
Carro
Grau do Relacionamento ou Cardinalidade Quando temos um relacionamento entre duas entidades, o nmero de ocorrncias de uma entidade que est associado a ocorrncias 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 atravs de trs possibilidades: Um-para-Um (1:1) Um-para-Muitos (1:N) Muitos-para-Muitos (N:N) ou (M:N)
o grau de ligao 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 direes. Relacionamento Um-para-Um (1:1) 1
Marido
Casado
1
Esposa
Pois um Marido s casado com uma Esposa, e, tambm, uma esposa s estar casada com um Marido. Cardinalidade Mnima e Mxima
mnimo mximo
Curso
1,1
Coorden a
1,1
Coordenador
Pgina 27
Administrao e Projeto de Banco de Dados Um Curso coordenado por no mnimo 1 e no mximo 1 coordenador. Um coordenador coordena no mnimo 1 e no mximo 1 curso.
PD Txtil Eletrnica
Douglas Pedro Ana
Relacionamento Um-para-Muitos (1:N) 1

Possui
Empresa
Filial
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 no poder ser de nenhuma outra. Cardinalidade Mnima e Mxima
0,N 0,1
Vendedor
Atend e
Regio
Um vendedor atende zero ou uma regio. Uma regio atendida por zero ou muitos vendedores.
Mrio Carla Joo Ana Campinas Piracicaba Sorocaba
Pgina 28
Relacionamento Muitos-para-Muitos (N:N)

N Livro N Autor
Escrit o
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. Cardinalidade Mnima e Mxima
0.N Fornecedor Forne ce 0.N Produto
Um fornecedor fornece zero ou muitos produtos. Um produto fornecido por zero ou muitos fornecedores.
W X Y Z
A B C D E
Pgina 29
Participao Outra restrio muito importante a participao. A participao define a existncia de uma entidade atravs do relacionamento, podendo ser parcial ou total. Veja um exemplo.
Empregado Jos Maria Fernanda Moacir Pedro Paula Luiz
Gerencia Departamento
Compras Projetos RH
Empregado
Gerenc ia
Departamento
A participao do empregado parcial, pois nem todo empregado gerencia um departamento, porm a participao 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 restries so chamadas de restries estruturais.
Pgina 30
Administrao e Projeto de Banco de Dados 1.1.1 Alguns critrio fraca sentido existir. Consideraes sobre Entidades Fortes e Entidades Fracas autores adotam, para fins de caracterizao de uma entidade, um que as classifica em fortes (regulares) ou fracas. Onde uma entidade uma entidade cuja existncia depende de alguma outra entidade, no de que ela, no poder existir se essa outra entidade tambm no
Esta caracterizao se d atravs da analise de existncia de duas condies bsicas: Dependncia de existncia.
Se uma entidade B depender de uma entidade A para existir, teremos em B uma entidade fraca, enquanto que A, se no depender de ningum para existir, ser considerada uma entidade forte. Dependncia de identificador.
Se uma entidade no possui atributos suficientes para formar uma chave primria, este tipo de entidade considerado uma entidade fraca. Do ponto de vista de modelagem conceitual, assim como a dependncia de existncia este tipo de critrio pode ser visto como dispensvel, pois sua importncia ser reconhecida sob o ponto de vista de projeto lgico, onde as chaves identificadoras, utilizadas como diferenciadores entre instncias dos elementos, ou como mtodo de endereamento de registro, passam a ter papel vital durante a o processo de estrutura de dados. A relao entre um entidade forte e uma fraca deve ser 1:N. Por exemplo, em um modelo de cadastro de funcionrios, poderamos 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 no poderiam existir sem um empregado no fosse cadastrado. Em particular se algum empregado for excludo, todos os seus dependentes tambm devem ser excludos. Um conjunto de entidades fracas identificado no modelo E-R pela linha dupla usada no retngulo e no losango do relacionamento correspondente. No diagrama abaixo, o conjunto de entidades fracas pagamento dependente do conjunto de entidades fortes Emprstimo pelo conjunto de relacionamento pagamento_emprstimo. A figura tambm apresenta o uso de linhas duplas para identificar participao total a participao do conjunto de entidades (fracas) pagamento no relacionamento pagamento_emprstimo total, significando que todo o pagamento precisa estar relacionado via pagamento_emprstimo a alguma conta.
Pgina 31
Total
Total_pagto
Data_Pagt o
Emprstimo
Pagamento_E Pagamento_empr stimo mprstimo
Pagamento
Nmero_emprstimo
Nmero_pagamento
Relacionamentos Reflexivos (auto-relacionamento) So os relacionamentos que ocorrem entre as ocorrncias de uma mesma entidade. Normalmente eles representam algum tipo de hierarquia.
0,N Funcionrio 1,1

Gerenci a
Funcionrio gerencia 0 ou muitos funcionrios. Funcionrio gerenciado por um nico funcionrio.
Extenses do Modelo Entidade x Relacionamento

O modelo de dados Entidade x Relacionamentos, como proposto por Peter Chen, tem sido usado efetivamente para a comunicao do usurio final, apresentando entidades e relacionamentos. Entretanto, quando usado para integrar diferentes modelos conceituais com diferentes usurios finais, fica severamente limitado at que se utilize um conceito de abstrao de dados denominado generalizao. Relacionamentos entre Mltiplas Entidades At o momento analisamos apenas situaes 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 trs, quatro, cinco ou uma quantidade indeterminada.
Pgina 32
Administrao e Projeto de Banco de Dados Os relacionamentos entre mltiplas entidades expressam um fato em que todas as entidades ocorrem simultaneamente, ou seja, todas as ocorrncias do relacionamento possuem, sempre, ligaes com todas as entidades envolvidas no relacionamento. No possvel um relacionamento triplo (Ternrio), em um determinado momento, transformar-se em duplo (Binrio). O diagrama abaixo representa uma situao de relacionamento que envolve trs entidades simultaneamente, a este tipo de relacionamento triplo, damos o nome de Relacionamento Ternrio.
1 1 atu a
Tcnico
Projeto
Notebook
Um tcnico que atua em um projeto utiliza um notebook. Um notebook utilizado em um projeto por um tcnico. Um tcnico com um notebook atua em um projeto.
Entidade associativa Um relacionamento uma associao entre entidades. Na modelagem ER no 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 situaes em que desejvel permitir a associao de uma entidade a um relacionamento. Vejamos um exemplo:
N Mdico
Consult
N Paciente a
Suponha que seja necessrio modificar este relacionamento da seguinte forma. necessrio saber que medicamentos existem e que medicamentos foram prescritos em cada consulta. Para saber que medicamentos existem, cria-se uma nova entidade, Medicamento. A questo agora : com que entidade existente deve estar relacionada a nova entidade? Se Medicamento fosse relacionado a Mdico, ter-se-ia apenas a informao de que mdico prescreveu que medicamentos, faltando a informao do paciente que os teve prescritos. Por outro lado, Rudson Kiyoshi Souza Carvalho Pgina 33
Administrao e Projeto de Banco de Dados se Medicamento fosse relacionado Paciente, faltaria a informao do Mdico que prescreveu o medicamento. Assim, deseja-se relacionar a prescrio do Medicamento consulta, ou seja, deseja-se relacionar um relacionamento prescrio com da entidade (Medicamento) a um relacionamento (Consulta), o que no est previsto na abordagem ER. Para tal, foi criado um conceito especial, o de entidade associativa. Uma entidade associativa nada mais que a redefinio de um relacionamento, que passa a ser tratado como se fosse tambm uma entidade. Graficamente isso feito como mostrado na figura abaixo.
N Mdico
Consult
N Paciente a N
Prescrio
Medicamento
O retngulo 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 tambm uma entidade, possvel associa-l atravs de relacionamentos a outras entidades, conforme a figura apresentada acima.
Agregao O termo agregao tem sido utilizado pelas tcnicas de modelagem de sistemas nos mais variados conceitos, porm o conceito lanado em Modelagem de Dados refere-se viso 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, no existem relacionamentos entre relacionamentos; uma inverdade conceitual. Para que exista o relacionamento de uma agregao com outra entidade necessria a existncia de dependncia entre os fatos, ou seja, um fato somente acontece aps a existncia do primeiro fato.
Pgina 34
Administrao e Projeto de Banco de Dados No diagrama abaixo o Servio s ser utilizado quando um cliente se hospedar em um quarto, o relacionamento utiliza depende do relacionamento de hospeda-se.
Cliente
Hospedase
Quarto
Utiliza
N
Servios
Generalizao (Supertipos) e Especializao (Subtipos) Quando estamos em busca da visualizao dos dados de um negcio, importante atentar ao nvel de abstrao em que estamos atuando, pois quando definimos uma entidade, estamos com a viso de uma classe genrica de dados que pode estar incorporando, diversas outras classes de dados. Generalizao Ao buscarmos as entidades presentes em um dado negcio, pode ser realizado de modo bottom-up (baixo para cima), no qual podemos reconhecer vrios conjuntos de entidades com atributos em comum, ento, estes atributos comuns so sintetizados em um conjunto de entidades de alto nvel. Por exemplo, ao modelarmos um sistema hospitalar, podemos encontrar entidades como Pediatra, Neurologista, Cardiologista, Clnico Geral, entre outros, e ao analisarmos as caractersticas de cada entidade, podemos perceber atributos em comum como nome, sexo, data nascimento e tratando tais entidades de forma mais genrica, podemos concluir que todas estas pessoas so mdicos. Dentro do contexto de modelagem botton-up, alguns autores classificam a entidade generalizada mdico como um supertipo.
Pgina 35
Mdico
Pediatra
Neurologista
Clnico Geral
Cardiologista
Ento 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 insero de um atributo qualificador para as ocorrncias de cada uma. Especializao A especializao justamente o inverso da generalizao que o processo de analise botton-up (de baixo para cima) tratado, ao tratarmos da especializao, nos ocorre o processo inverso de anlise o processo top-down (de cima para baixo) que o caso da especializao, ou seja, um conjunto de entidades pode conter subgrupos (subtipos) de entidades que so de alguma forma, diferentes de outras entidades do conjunto, continuando com o exemplo do digrama anterior, ao analisarmos nossa entidade a partir de mdico, pode-se reconhecer subgrupos (subtipos) de mdico, como Pediatra, Neurologista, Cardiologista, Clnico Geral, entre outros. Generalizao X Especializao Na pratica, a generalizao o inverso da especializao. No processo de modelagem novos nveis de representao sero, diferenciadas (especializao) ou sintetizadas (generalizao). Generalizao Mdico Especializao Pediatra, Neurologista, Cardiologista, Clnico Geral
Pgina 36
Bancos de Dados Relacionais Definio

Foi criado por Edgar F. Codd na dcada de 70. A abordagem relacional est baseada no princpio de que as informaes em uma base de dados podem ser consideradas como relaes matemticas e que esto representadas de maneira uniforme, atravs do uso de tabelas bidimensionais. Este princpio coloca os dados (entidades e relacionamentos) dirigidos para estruturas mais simples de armazenar dados, que so as tabelas, e nas quais a viso do usurio privilegiada. A grande diferena existente quando se trabalha com bancos de dados relacionais em relao aos ambientes tradicionais, pode ser exemplificada da seguinte forma: Em um ambiente tradicional, a funo de acender um fsforo seria descrita de forma exatamente procedural, passo a passo: Abrir a caixa de fsforos. Verificar se existem palitos. Levar o palito lateral da caixa. Riscar o palito. Testar se acendeu ou no. Etc. Em um ambiente de banco de dados relacional devemos mentalizar que as instrues todas se resumem em uma nica, uma operao realizada em conjunto. ACENDA UM FSFORO Para definir e explicar claramente suponhamos que queremos retirar de uma sala de aula todos os alunos que possuem mdia abaixo de 5 pontos. Em um ambiente tradicional seria perguntado a cada aluno: Sua mdia abaixo de 5 ?
Se a resposta for sim, pediramos que sasse. Se fosse no, ele ficaria. Em um ambiente de banco de dados relacional, bastaria realizar uma operao lgica: Saiam todos que possuam mdia menor do que 5.
Pgina 37
Tabela Relacional
Apresentamos abaixo uma relao de conceitos que definem uma tabela relacional: Cada tabela chamada de relao. 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. No h duas linhas iguais. A ordem das colunas tambm irrelevante. Cada tabela tem nome prprio, distinto de qualquer outra tabela no banco de dados. Exemplo: Tabela de Funcionrios: Nome Joo Carlos Carlos Brito Silvia Moraes Cludia Tereza Pedro Jlio Pedro Jlio Sexo M M F F M M Matrcula 373 872 963 161 292 574 Departamento TI-Operaes TI-Programao TI-Anlise TI-Gerncia RH TI-Anlise Cargo Operador Programador I Analista Sist. II Secretria Diretor Analista Sist. I
Vamos analisar os dados: As matrculas no 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 no est desenvolvida para nenhuma finalidade de classificao ou ordem de leitura dos dados. Nenhuma linha se repete. Podemos ter duas pessoas com o mesmo nome, porm com matrculas diferentes.
Pgina 38
O conceito de Chave no Modelo Relacional

Chave Primria (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. Ento dizemos que esta coluna ou conjunto de colunas forma a chave primria da tabela. Na nossa tabela de funcionrio, qual coluna ou conjunto de concatenadas forma um identificador nico para cada linha da tabela? Nome Joo Carlos Carlos Brito Silvia Moraes Cludia Tereza Pedro Jlio Pedro Jlio Sexo M M F F M M Matrcula 373 872 963 161 292 574 Departamento TI-Operaes TI-Programao TI-Anlise TI-Gerncia RH TI-Anlise colunas
Cargo Operador Programador I Analista Sist. II Secretria Diretor Analista Sist. I
Nome? Com certeza no, pois se repete. Sexo? Tambm se repete. Departamento tambm no e cargo e salrio sozinhos tambm no nos dizem nada. Sobra neste caso a nica coluna que no tem valores repetidos, que a matrcula. Existe somente um valor de matrcula para cada linha, o qual no se repete, logo podemos determinar que a Matrcula a chave primria da tabela de Funcionrios. Vamos agora observar uma tabela mais complicada, em que tenhamos que realizar um estudo maior para determinar a chave primria.
Pgina 39
Administrao e Projeto de Banco de Dados Tabela de Consumos Bebida Cerveja Chopp Cerveja Refrigerante Mate Caf Suco Mate Chopp gua Caf Qtde 2 3 2 3 1 1 1 1 4 1 1 Valor Unit. 3,00 2,00 3,00 2,00 1,50 0,80 3,00 1,50 2,00 1,00 0,80 Local Consumo Restaurante Bar Restaurante Restaurante Frigobar Restaurante Service Room Restaurante Bar Frigobar Restaurante Quarto 101 203 101 203 407 203 505 407 203 101 203 Data 22/01/2001 19/01/2001 23/01/2001 20/01/2001 21/01/2001 18/01/2001 22/01/2001 21/01/2001 19/01/2001 18/01/2001 18/01/2001 Hora 14:30 11:00 14:30 08:45 16:30 08:00 21:30 16:30 17:10 08:30 18:00 Valor 6,00 8,00 6,00 6,00 1,50 0,80 3,00 1,50 8,00 1,00 0,80
Qual coluna ou conjunto de colunas poderamos definir como identificador nico de cada linha da tabela ? Poderia ser bebida? No. Quarto, tambm no. 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: Bebida Cerveja Cerveja Qtde 2 2 Valor Unit. 3,00 3,00 Local Consumo Restaurante Restaurante Quarto 101 101 Data 22/01/200 1 23/01/200 1 Hora 14:30 14:30 Valor 6,00 6,00
Se acrescentarmos o local de consumo concatenao das colunas referidas, ainda no teramos um identificador nico. Bebida Cerveja Cerveja Qtde 2 2 Valor Unit. 3,00 3,00 Local Consumo Restaurante Restaurante Quarto 101 101 Data 22/01/200 1 23/01/200 1 Hora 14:30 14:30 Valor 6,00 6,00
Como os consumos foram realizados em datas diferentes, podemos inserir a data na composio da chave primria. Bebida Cerveja Cerveja Qtde 2 2 Valor Unit. 3,00 3,00 Local Consumo Restaurante Restaurante Quarto 101 101 Data 22/01/200 1 23/01/200 1 Hora 14:30 14:30 Valor 6,00 6,00
Desta vez os valores no se repetiriam. Porm, observe o consumo de mate pelo quarto 407.
Pgina 40
Administrao e Projeto de Banco de Dados Bebida Mate Mate Qtde 1 1 Valor Unit. 1,50 1,50 Local Consumo Frigobar Restaurante Quarto 407 407 Data Consumo 21/01/200 1 21/01/200 1 Hora Consumo 16:30 16:30 Valor Total 1,50 1,50
Eles foram consumidos na mesma data, mas como o local de consumo diferente, isso garante a integridade de nossa chave primria. Porm, o mesmo no ocorre com as duas linhas a seguir: Bebida Caf Caf Qtde 1 1 Valor Unit. 0,80 0,80 Local Consumo Restaurante Restaurante Quarto 203 203 Data Consumo 18/01/200 1 18/01/200 1 Hora Consumo 08:00 18:00 Valor Total 0,80 0,80
Aconteceram dois consumos de caf pelo mesmo quarto (hspede), no mesmo local e na mesma data. Isso nos diz que a chave primria definida at agora no 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 primria, passaramos a ter duas linhas distintas. Bebida Caf Caf Qtde 1 1 Valor Unit. 0,80 0,80 Local Consumo Restaurante Restaurante Quarto 203 203 Data Consumo 18/01/200 1 18/01/200 1 Hora Consumo 08:00 18:00 Valor Total 0,80 0,80
Essa ento a nossa chave primria: Bebida Local de consumo Quarto Data consumo Hora consumo
Dessa forma, no poderamos 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 invs de inserirmos duas linhas na tabela. Chave Estrangeira (Foreign Key) Quando dizemos que duas tabelas esto relacionadas atravs de atributos (colunas) comuns, devemos observar que esta coluna a chave primria em uma das tabelas. Na outra tabela, este atributo ir caracterizar o que chamamos de chave estrangeira, propiciando assim, uma ligao lgica (relacionamento) entre as tabelas. Exemplo: Rudson Kiyoshi Souza Carvalho Pgina 41
Departamento
Possui
Funcionrio
Cd_Depto Departamento 1 TI-Anlise 2 TI-Programao 3 TI-Operaes 4 RH 5 TI-Gerncia Chave Candidata Uma tabela Chave primria
Nome Joo Carlos Carlos Brito Silvia Moraes Cludia Tereza Pedro Jlio Pedro Jlio
Sexo Matrcula M 373 M 872 F 963 F 161 M 292 M 574
Depto 3 2 1 5 4 1
relacional pode assumir alternativas de identificador nico, ouestrangeira seja, Chave vria colunas ou concatenaes delas podem ter essa propriedade. Estes identificadores so candidatos chave primria. Como somente um poder ser o escolhido (uma tabela s pode ter uma chave primria que pode ser composta pela concatenao de mais de uma coluna), o restante passa a ser considerado como chave alternativa (secundria).
Chave Secundria (Secundary Key) Serve para definir uma segunda chave primria atravs da criao de ndices nicos de pesquisa. As chaves secundrias mantm a integridade das tabelas que possuem mais de uma chave candidata.
Regras de Integridade do Modelo Relacional

Integridade de Identidade A chave primria no pode conter um valor nulo (NULL). O NULL no o valor zero nem o caractere branco, simplesmente a no existncia de contedo nesse campo. Integridade Referencial Se uma determinada tabela A possui uma chave estrangeira, a qual chave primria em outra tabela B, ento ela deve ser: Igual a um valor de chave primria existente em B. Nula (null).
No pode existir na chave estrangeira, um valor que no exista na tabela na qual ela chave primria. As regras de integridade do modelo relacional representam a garantia de que as tabelas guardam informaes compatveis. So de extrema importncia para a confiabilidade das informaes contidas no banco de dados.
Pgina 42
Caractersticas do Modelo Relacional

Uma tabela acessvel por qualquer campo (atributo) independente se este declarado como chave ou no. O relacionamento entre as tabelas no existe fisicamente, pois este relacionamento apenas lgico e representado atravs das chaves estrangeiras. Utilizao de linguagens no procedurais (SQL). Os ambientes relacionais possuem um otimizador estratgico para escolher o melhor caminho para a recuperao dos dados.
Derivao do Modelo Entidade x Relacionamento para o Modelo Lgico Relacional

Nesta etapa o desenvolvedor ir passar a viso do modelo conceitual para o modelo lgico relacional, seguindo algumas regras de converso.
Regras de Converso
Existem regras precisas que no do margem a erros, sendo que uma vez projetado o diagrama ER, as tabelas que representam o ER num nvel mais baixo podem ser obtidas de forma clara. Mapeamento de Entidades Toda entidade torna-se uma tabela carregando todos os atributos definidos para ela. Mapeando atributos Cada atributo vira um campo da tabela criada. Os atributos identificadores viram a chave primria da tabela. Relacionamento 1:N (envolvendo entidades distintas) A entidade (tabela) cuja cardinalidade N recebe o atributo identificador da entidade cuja cardinalidade 1 (chave estrangeira). Exemplo:
1,1 0,N Possui
Departamento
Funcionrio
Departamento Cd_Depto Departamento 1 TI-Anlise 2 TI-Programao 3 TI-Operaes 4 RH 5 TI-Gerncia Rudson Kiyoshi Souza Carvalho
Chave primria
Funcionrio Nome Joo Carlos Carlos Brito Silvia Moraes Cludia Tereza Pedro Jlio Pgina Pedro Jlio 43
Sexo M M F F M M
Matrcula 373 872 963 161 292 574
Depto 3 2 1 5 4 1
Chave estrangeira
Relacionamento 1:N (envolvendo auto-relacionamento) Incluir a chave primria da entidade na prpria entidade como chave estrangeira.
0,N
Funcionrio
1,1
Gerenci a
Funcionrio Matrcula 373 872 963 161 292 574
Nome Joo Carlos Carlos Brito Silvia Moraes Cludia Tereza Pedro Jlio Pedro Jlio
Sexo M M F F M M
Depto 3 2 1 5 4 1
Matrcula_Chefe 161 161 161 056 010 161
Relacionamento 1:1 As entidades (tabelas) envolvidas neste relacionamento carregaro o identificador da outra (uma ou outra ou ambas) conforme a convenincia do projeto (de acordo com o acesso a essas tabelas).
Funcionrio
1,1
Chefia
0,1
Departamento
Podemos colocar a chave matrcula na tabela de departamentos, representando que um departamento possui um chefe.
Pgina 44
Departamento Cd_Depto Departamento 1 TI-Anlise 2 TI-Programao 3 TI-Operaes 4 RH 5 TI-Gerncia
Chefe 574 872 373 292 161
Funcionrio Nome Joo Carlos Carlos Brito Silvia Moraes Cludia Tereza Pedro Jlio Pedro Jlio
Sexo M M F F M M
Matrcula 373 872 963 161 292 574
Depto 3 2 1 5 4 1
Podemos tambm colocar a chave departamento na tabela de funcionrios, representando que um funcionrio pode chefiar um departamento. Note que podemos ter funcionrio que no chefiam nenhum departamento.
Pgina 45
Departamento Cd_Depto Departamento 1 TI-Anlise 2 TI-Programao 3 TI-Operaes 4 RH 5 TI-Gerncia
Empregado Nome Joo Carlos Carlos Brito Silvia Moraes Cludia Tereza Pedro Jlio Pedro Jlio
Sexo M M F F M M
Matrcula Chefia Depto 373 3 872 963 161 5 292 574 1
Trabalha Depto 3 2 1 5 4 1
Tambm poderamos colocar a chave estrangeira em ambas as tabelas (alternativa menos utilizada). Departamento Cd_Dept Departamento o 1 TI-Anlise 2 TIProgramao 3 TI-Operaes 4 RH 5 TI-Gerncia Funcionrio Nome Sexo Joo Carlos Carlos Brito Silvia Moraes Cludia TerezaJlio Pedro Pedro Jlio M M F F M M
Chefe 574 872 373 292 161
Matrcula 373 872 963 161 292 574
Chefia Depto 3 2 5 4 1
Trabalha Depto 3 2 1 5 4 1
Relacionamento N:N O relacionamento torna-se uma tabela carregando os atributos identificadores das entidades relacionadas e os atributos do relacionamento (quando houver). Funcionrio
0,N 0,N
Alocado
Projeto
Funcionrio Nome Joo Carlos Carlos Brito Silvia Moraes Cludia Tereza Pedro Jlio Pedro Jlio
Sexo M M F F M M
Matrcula 373 872 963 161 292 574
Projeto Cd_Projeto 1 2 3
Projeto Data Warehouse RH Folha de Pagamento B.I. Marketing
Projeto_Funcionrio Matrcula Cd_Pojeto 373 872 373 1 3 2
Horas_Alocadas 100 300 200
Relacionamento Mltiplo O relacionamento mapeado em uma tabela, cuja chave primria formada pela concatenao de todas as chaves estrangeiras. Rudson Kiyoshi Souza Carvalho Pgina 46
Funcionrio
0,N
Alocado
0,N
Projeto
0,N
Conhecimento
Projeto Cd_Projeto 1 2 3 Funcionrio Nome Joo Carlos Carlos Brito Silvia Moraes Cludia Tereza Pedro Jlio Pedro Jlio Exemplo:
Projeto Data Warehouse RH Folha de Pagamento B.I. Marketing
Conhecimento Cd_Conhec Conhecimento 1 Oracle Discovere 2 PL/SQL 3 SQL Server Funcionrio-Projeto-Conhecimento Matrcula Cd_Pojeto Cd_conhec 373 872 574 574 Generalizaes 1 3 2 2 1 2 3 2
Sexo M M F F M M
Matrcula 373 872 963 161 292 574
Dado um conjunto funcionrio, existe uma variao para este, pois existem funcionrios que so engenheiros, outros so vendedores e assim por diante, sendo que podem existir variaes nos atributos de um funcionrio de acordo com o seu cargo. O artifcio que temos a criao de subconjuntos para os casos nos quais as informaes variam. Um elemento funcionrio s pode ter um e somente um subconjunto. As informaes dos engenheiros sero completadas pelo subconjunto engenheiro, as do vendedor pelo subconjunto vendedor e assim por diante. Funcionrio Os subconjuntos tornam-se tabelas carregando o identificador do conjunto ao qual pertencem.
Gerente
Engenheiro
- Matrcula
Secretria
- Matrcula - Ajuda de custo
- Hora Extra - Despesa Extra Pgina 47 - Placa Carro
- Matrcula - Lngua Estrangeira - Curso

- Especialidade
Pgina 48
Funcionrio Matrcula 4534 6547 7734 1198 3289
Nome Soraia Mattos Breno Medeiros Gustavo Borges Ana Ferreira Telma Ribeiro
Funo Ger Eng Eng Eng Sec
Func_Gerente
Mat Aj 4534 Custo 120 Espec Eletr.
Func_Secretaria
Mat 4534 Lngua Ingls Curso Secret.
Func_Engenheiro
Mat 4534 7734 3289 5 23 HR Ext 120 Desp Ext 240 Placa AHA8909 ACA2356 JOL1234
Normalizao de Dados Definio

O conceito de normalizao foi introduzido por E. F. Codd em 1972. Inicialmente Codd criou as trs primeiras formas de normalizao chamando-as de: primeira forma normal (1NF), segunda forma normal (2NF) e terceira forma normal (3NF). Uma definio mais forte da 3NF foi proposta depois por BoyceCodd, e conhecida como forma normal de Boyce-Codd (FNBC). Atravs do processo de normalizao pode-se, gradativamente, substituir um conjunto de entidades e relacionamentos por um outro, o qual se apresenta "purificado" em relao s anomalias de atualizao (incluso, alterao e excluso) as quais podem causar certos problemas, tais como: grupos repetitivos (atributos multivalorados) de dados; variao temporal de certos atributos, dependncias funcionais totais ou parciais em relao a uma chave concatenada; redundncias de dados desnecessrias; perdas acidentais de informao; dificuldade na representao de fatos da realidade observada; dependncias transitivas entre atributos.
Pgina 49
Administrao e Projeto de Banco de Dados Normalizao de relaes portanto uma tcnica que permite depurar um projeto de banco de dados, atravs da identificao de inconsistncias (informaes em duplicidade, dependncias funcionais mal resolvidas, etc). medida que um conjunto de relaes passa para uma forma normal, vamos construindo um banco de dados mais confivel. O objetivo da normalizao no eliminar todas as inconsistncias, e sim control-las. Primeira Forma Normal (1FN) Uma relao est na primeira forma normal se os valores de seus atributos so atmicos (simples, indivisveis) e monovalorados. Em outras palavras, FN1 no permite relaes dentro de relaes ou relaes como atributos de tuplas. Uma tabela est na primeira forma normal quando seus atributos no contm grupos de repetio. Exemplo: Estrutura original: Arquivo de Vendas (Num Venda, Data emisso, Cod. do Cliente, Nome do cliente, Endereo do cliente, CGC do cliente, Relao das mercadorias vendidas (onde para cada mercadoria temos: Cdigo da Mercadoria, Descrio da Mercadoria, Quantidade vendida, Preo de venda e Total da venda desta mercadoria) e Total Geral da Nota). Analisando a estrutura acima, observamos que existem vrias mercadorias em uma nica Venda, sendo, portanto elementos repetitivos que devero ser retirados. Estrutura na primeira forma normal (1FN): Arquivo de Vendas (Num Venda, Data emisso, Cdigo do Cliente, Nome Cliente, Endereo do cliente, CGC do cliente e Total Geral da Nota). Arquivo de Itens da Venda (Num Venda, Cdigo da Mercadoria, Descrio da Mercadoria, Quantidade vendida, Preo 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 compem a estrutura original, excluindo os elementos repetitivos. Segundo estrutura (Arquivo de Itens da Venda): Dados que compem os elementos repetitivos da estrutura original, tendo como chave o campo chave da estrutura original (Num Venda) e o campo chave da estrutura de repetio (Cdigo da Mercadoria).
Pgina 50
Administrao e Projeto de Banco de Dados Segunda Forma Normal (2FN) - Dependncias Funcionais Para uma tabela estar na segunda forma normal, alm de estar na primeira forma ela no deve conter dependncias funcionais de parte da chave primria. Um jeito de verificar esta norma refazer a leitura dos campos fazendo a pergunta: Este campo depende de toda a chave? Se no depender de toda a chave temos uma dependncia funcional. Exemplo: Estrutura na primeira forma normal (1FN): Arquivo de Vendas (Num Venda, Data emisso, Cdigo do Cliente, Nome do cliente, Endereo do cliente, CGC do cliente e Total Geral da Nota). Arquivo de da Itens Vendas (Num Venda, Cdigo da Mercadoria, Descrio da Mercadoria, Quantidade vendida, Preo de venda e Total da venda desta mercadoria) Estrutura na segunda forma normal (2FN): Arquivo de Vendas (Num Venda, Data emisso, Cdigo do Cliente, Nome do cliente, Endereo do cliente, CGC do cliente e Total Geral da Nota). Arquivo de Itens da Vendas (Num Venda, Cdigo da Mercadoria, Quantidade vendida e Total da venda desta mercadoria). Arquivo de Mercadorias (Cdigo da Mercadoria, Descrio da Mercadoria, Preo de venda). Como resultado desta etapa, houve um desdobramento do arquivo de Itens da Venda (o arquivo de Vendas, no foi alterado, por no possuir chave composta) em duas estruturas a saber: Primeira estrutura (Arquivo de Itens da Vendas): Contm os elementos originais, sendo excludos os dados que so dependentes apenas do campo Cdigo da Mercadoria. Segundo estrutura (Arquivo de Mercadorias): Contm os elementos que so identificados apenas pelo Cdigo da Mercadoria, ou seja, independentemente da Nota Fiscal, a descrio e o preo de venda sero constantes. - Terceira Forma Normal (3FN) - Dependncias Transitivas Para uma tabela estar na terceira forma normal, alm de estar na segunda forma ela no deve conter dependncias transitivas. Um jeito de verificar esta norma refazer a leitura dos campos fazendo a pergunta: Este campo depende de outro que no seja a chave? Se ele depender temos uma dependncia transitiva..
Pgina 51
Administrao e Projeto de Banco de Dados Exemplo: Estrutura na segunda forma normal (2FN): Arquivo de Vendas (Num Venda, Data emisso, Cdigo do Cliente, Nome do cliente, Endereo do cliente, CGC do cliente e Total Geral da Nota). Arquivo de Itens da Venda (Num Venda, Cdigo da Mercadoria, Quantidade vendida e Total da venda desta mercadoria). Arquivo de Mercadorias (Cdigo da Mercadoria, Descrio da Mercadoria, Preo de venda). Estrutura na terceira forma normal (3FN): Arquivo de Vendas (Num Venda, Data emisso, Cdigo do Cliente e Total Geral da Nota). Arquivo de Itens da Venda (Num Venda, Cdigo da Mercadoria, Quantidade vendida e Total da venda desta mercadoria). Arquivo de Mercadorias (Cdigo da Mercadoria, Descrio da Mercadoria, Preo de venda). Arquivo de Clientes (Cdigo do Cliente, Nome do cliente, Endereo do cliente e CGC do cliente). Como resultado desta etapa, houve um desdobramento do arquivo de Vendas, por ser o nico que possua campos que no eram dependentes da chave principal (Num Venda), uma vez que independente da Venda, o Nome, Endereo e CGC do cliente so inalterados. Este procedimento permite evitar inconsistncia nos dados dos arquivos e economizar espao por eliminar o armazenamento freqente e repetidas vezes destes dados. A cada venda feita para o cliente, haver o armazenamento destes dados e poder ocorrer divergncia entre eles. As estruturas alteradas foram pelos motivos, a saber: Primeira estrutura (Arquivo de Vendas): Contm os elementos originais, sendo excludos os dados que so dependentes apenas do campo Cdigo do Cliente (informaes referentes ao cliente). Segundo estrutura (Arquivo de Clientes): Contm os elementos que so identificados apenas pelo Cdigo do Cliente, ou seja, independente da Venda, o Nome, Endereo e CGC dos clientes sero constantes. Aps a normalizao, as estruturas dos dados esto projetadas para eliminar as inconsistncias e redundncias dos dados, eliminando desta forma qualquer problema de atualizao e operacionalizao do sistema. A verso final dos dados poder sofrer alguma alterao, para atender as necessidades especficas do sistema, a critrio do analista de desenvolvimento durante o projeto.
Pgina 52
Administrao e Projeto de Banco de Dados Quarta Forma Normal (4FN) Na grande maioria dos casos, as entidades normalizadas at a 3FN so fceis de entender, atualizar e de se recuperar dados. Mas s vezes podem surgir problemas com relao a algum atributo no chave, que recebe valores mltiplos para um mesmo valor de chave. Esta nova dependncia recebe o nome de dependncia multivalorada que existe somente se a entidade contiver no mnimo trs atributos. Uma entidade que esteja na 3FN tambm estar na 4FN, se ela no contiver mais do que um fato multivalorado a respeito da entidade descrita. Exemplo: Dado a tabela a seguir. Cd Funcionrio 1234 1234 1234 1234 Habilidade SQL Server Oracle Oracle Access Idioma Ingls Francs Ingls Alemo
Como podemos observar, esta entidade tenta conter dois fatos multivalorados: as diversas habilidades de um funcionrio e os diversos idiomas. Com isso apresenta uma dependncia multivalorada entre Cdigo Funcionrio e Habilidade e entre Cdigo Funcionrio e Idioma. Embora esteja na 3FN, ao conter mais de um fato multivalor, torna a sua atualizao muito difcil.
Para passarmos a entidade acima para a 4FN, necessria a realizao de uma diviso da entidade original, em duas outras entidades, ambas herdando a chave Cdigo Funcionrio e concatenado, em cada nova entidade, com os atributos Habilidade e Idioma. Funcionrio-Habilidade Cd Funcionrio 1234 1234 1234 Habilidade SQL Server Oracle Access
Funcionrio -Idioma Cd Funcionrio 1234 1234 1234 Idioma Ingls Francs Alemo
Pgina 53
Quinta Forma Normal (5FN) Um registro no pode ser reconstrudo a partir de vrios tipos de registros menores. Exemplo: Os vendedores representam as empresas. As empresas fazem produtos. Os vendedores vendem os produtos.
Caso mais geral (permite qualquer combinao): Vendedor Smith Smith Empresa Ford GM Produto Carro Caminho
O Smith no vende nem caminhes da Ford, nem carros da GM. em uma alterao que ocorre o problema: Se um vendedor trabalha com um determinado produto, e ele representa uma empresa, ento ele vende esses produtos pela empresa. Vendedor Smith Smith Smith Smith Jones Empresa Ford Ford GM GM Ford Produto Carro Caminho Carro Caminho Carro
Podemos reconstruir todos os fatos verdadeiros em trs tabelas em vez de uma: Vendedor Smith Smith Jones Empresa Ford GM Ford Empresa Ford Ford GM GM Produto Carro Caminho Carro Caminho
Vendedor Smith Smith Jones
Produto Carro Caminho Carro
Pgina 54
Administrao e Projeto de Banco de Dados Problemas com a forma da tabela 1: Os fatos so registrados vrias 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 progresso geomtrica, enquanto as tabelas normalizadas crescem em progresso aritmtica. Para grandes operaes, isso faz uma grande diferena: 100.000 x 100.000 bem maior do que 100.000 + 100.000.
mais fcil escrever as regras comerciais a partir da quinta normal: As regras so mais explcitas. (Cadeias de suprimentos tm todos os tipos de problemas da 5FN).
Um exemplo de um conjunto sutil de condies: No-normal Vendedor Smith Smith Smith Smith Jones Jones Brown Brown Brown Brown Empresa Ford Ford GM GM Ford Ford Ford GM Toyota Toyota Produto Carro Caminho Carro Caminho Carro Caminho Carro Carro Carro nibus
Na 5FN: Vendedor Smith Smith Jones Brown Brown Brown Empresa Ford GM Ford Ford GM Toyota Empresa Ford Ford GM GM Toyota Toyota Produto Carro Caminho Carro Caminho Carro nibus Vendedor Smith Smith Jones Jones Brown Brown Produto Carro Caminho Carro Caminho Carro nibus
Jones vende carros e a GM fabrica carros, mas Jones no representante da GM. Brown representante da Ford e a Ford fabrica caminhes, mas Brown no vende caminhes.
Pgina 55
Administrao e Projeto de Banco de Dados Brown representante da Ford e Brown vende nibus, mas a Ford no fabrica nibus.
Pgina 56
Bibliografia
C. J. Date - Introduo a Sistemas de Banco de Dados, Elsevier 8 Edio Paulo Cougo - Modelagem Conceitual e Projeto de Bancos de dados, Elsevier17 Triagem Felipe Machado e Maurcio Abreu - Projeto de Banco de Dados Uma Viso Prtica, 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 implementao. Sexta edio (traduo). LTC 1999 Carlos Alberto Heuser Projeto de Banco de dados, Bookman. Fernando Martins de Oliveira Apostila Banco de Dados. Shigueru Watanabe Aulas e apresentaes de Banco de Dados. http://www.ime.usp.br/~andrers/aulas/bd2005-1/aula.html http://www.criarweb.com/artigos/modelos-banco-dados.html
Pgina 57

Ex Modelagem Good

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ex Modelagem Good

Enviado por

Direitos autorais:

Formatos disponíveis

Administrao e Projeto de Banco de Dados

Administrao e Projeto de banco de dados

Rudson Kiyoshi Souza Carvalho

Administrao e Projeto de Banco de Dados

Contedo.................................................................................2 Introduo e conceitos gerais.................................................5

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

Derivao do Modelo Entidade x Relacionamento para o Modelo Lgico Relacional.......................................................43

Administrao e Projeto de Banco de Dados

Rudson Kiyoshi Souza Carvalho

Administrao e Projeto de Banco de Dados

Introduo e conceitos gerais

Figura 1 Relao entre dado, informao e conhecimento.

Rudson Kiyoshi Souza Carvalho

Sistema de Banco de Dados

Rudson Kiyoshi Souza Carvalho

Rudson Kiyoshi Souza Carvalho

Administrao e Projeto de Banco de Dados

Rudson Kiyoshi Souza Carvalho

Administrao e Projeto de Banco de Dados Suporte a transaes

Rudson Kiyoshi Souza Carvalho

Administrao e Projeto de Banco de Dados

Rudson Kiyoshi Souza Carvalho

Administrao e Projeto de Banco de Dados

Figura 2 Os trs nveis da arquitetura.

Rudson Kiyoshi Souza Carvalho

Sistema de Gerenciamento de Bancos de Dados (SGBD)

Rudson Kiyoshi Souza Carvalho

Estrutura bsica de um sistema gerenciador de Banco de dados

Figura 3 Estrutura bsica de um SGBD

Rudson Kiyoshi Souza Carvalho

Figura 4 Estrutura expandida de um SGBD

Rudson Kiyoshi Souza Carvalho

Administrao e Projeto de Banco de Dados

Linguagens para Manipulao de Dados

Rudson Kiyoshi Souza Carvalho

Administrao e Projeto de Banco de Dados

Modelos de Bancos de Dados

Rudson Kiyoshi Souza Carvalho

Administrao e Projeto de Banco de Dados

Rudson Kiyoshi Souza Carvalho

Administrao e Projeto de Banco de Dados

Rudson Kiyoshi Souza Carvalho

Administrao e Projeto de Banco de Dados

Rudson Kiyoshi Souza Carvalho

Rudson Kiyoshi Souza Carvalho

Rudson Kiyoshi Souza Carvalho

utilizado para identificar unicamente uma linha da entidade.

Derivado: Pode ter um valor que derivvel de valores de outros atributos.

Derivado Multivalorado: Pode ser preenchido com muitos valores.

Rudson Kiyoshi Souza Carvalho

Data Nasc. Telefones

4. Identificar o relacionamento entre os objetos: Rudson Kiyoshi Souza Carvalho Pgina 26

Administrao e Projeto de Banco de Dados Relacionamento: Pessoa proprietria de Carro

Rudson Kiyoshi Souza Carvalho

Douglas Pedro Ana

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

Mrio Carla Joo Ana Campinas Piracicaba Sorocaba

Rudson Kiyoshi Souza Carvalho

Administrao e Projeto de Banco de Dados

Relacionamento Muitos-para-Muitos (N:N)

Rudson Kiyoshi Souza Carvalho

Administrao e Projeto de Banco de Dados

Empregado Jos Maria Fernanda Moacir Pedro Paula Luiz

Rudson Kiyoshi Souza Carvalho