Baixe o app para aproveitar ainda mais
Prévia do material em texto
Administração e Projeto de Banco de Dados Rudson Kiyoshi Souza Carvalho Página 1 Administração e Projeto de banco de dados 2010 Conceito de banco de dados. Modelagem conceitual de dados. Formas normais. Projeto lógico e físico, segundo o modelo relacional. Linguagem de definição e manipulação de dados. O padrão SQL. Concorrência de transações e mecanismos de manutenção de integridade, em sistemas de banco de dados. Views, Triggers, e Stored Procedures. Segurança e controle de acesso a informação. Sistemas de Informação e Processamento de dados Administração e Projeto de Banco de Dados Conteúdo Conteúdo ................................................................................. 2 Introdução 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 Usuários .................................................................................................. 7 Usuários finais: ....................................................................................... 8 Administrador de Banco de Dados (DBA) ..................................................... 8 Projetista de Banco de Dados (Administrador de Dados) ................................ 8 Analistas de Sistemas e Programadores de Aplicações .................................. 8 Por que um Sistema de Banco de Dados? .................................................... 9 Vantagens tecnológicas da utilização de um Sistema de Banco de Dados ......... 9 Quando não Utilizar um SGBD .................................................................. 10 Arquitetura de sistemas de banco de dados. .............................................. 11 Os três níveis da arquitetura: ................................................................... 11 Independência de Dados ......................................................................... 12 Sistema de Gerenciamento de Bancos de Dados (SGBD) ........................ 13 Funções do SGBD ................................................................................... 13 Estrutura geral do SGBD .......................................................................... 13 Linguagens para Manipulação de Dados ................................................. 16 Modelos de Bancos de Dados ................................................................... 17 O Modelo Hierárquico .............................................................................. 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 Lógico de Dados (MLD) ................................................................. 22 Modelo Físico 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 Página 2 Administração 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 Participação ........................................................................................... 30 Relacionamentos Reflexivos (auto-relacionamento) ..................................... 32 Extensões do Modelo Entidade x Relacionamento .................................. 32 Relacionamentos entre Múltiplas Entidades ................................................ 32 Entidade associativa ................................................................................ 33 Agregação ............................................................................................. 34 Generalização (Supertipos) e Especialização (Subtipos) ............................... 35 Generalização ........................................................................................ 35 Especialização ........................................................................................ 36 Generalização X Especialização ................................................................. 36 Bancos de Dados Relacionais ................................................. 37 Definição ................................................................................................ 37 Tabela Relacional ................................................................................... 38 O conceito de Chave no Modelo Relacional ............................................. 39 Chave Primária (Primary Key) .................................................................. 39 Chave Estrangeira (Foreign Key) .............................................................. 41 Chave Candidata .................................................................................... 42 Chave Secundária (Secundary Key) .......................................................... 42 Regras de Integridade do Modelo Relacional .......................................... 42 Integridade 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 .............................................................................. 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 Múltiplo .......................................................................... 46 Generalizações ....................................................................................... 47 Normalização de Dados ........................................................ 49 Definição ................................................................................................ 49 Primeira Forma Normal (1FN) ................................................................... 50 Segunda Forma Normal (2FN) - Dependências Funcionais ............................ 51 - Terceira Forma Normal (3FN) - Dependências Transitivas .......................... 51 Quarta Forma Normal (4FN) ..................................................................... 53 Quinta Forma Normal (5FN) ..................................................................... 54 Bibliografia ............................................................................................ 57 Rudson Kiyoshi Souza Carvalho Página 3 Administração e Projeto de Banco de Dados Rudson Kiyoshi Souza Carvalho Página 4 Administração e Projeto de Banco de Dados Introdução e conceitos gerais Antes de definir banco de dados, vamos definir alguns conceitos básicos ligados ao mesmo, como dado, informação e conhecimento. Dado é qualquer elemento identificado em sua forma bruta que, por si só, não conduz a uma compreensão de determinado fato ou situação (Oliveira, 2005) Informação é o dado trabalhadoque agrupado de maneira lógica permite aos usuários desta informação tomar decisões. (Oliveira, 2005) Conhecimento é a informação associada em múltiplos contextos. Segundo Laudon e Laudon 1999, conhecimento é o conjunto de ferramentas conceituais e categorias usadas pelos seres humanos para criar, colecionar, armazenar e compartilhar a informação. Figura 1 Relação entre dado, informação e conhecimento. 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 implícito. Porém, o significado do termo “banco de dados” é mais restrito que simplesmente a definição dada acima. Um banco de dados possui as seguintes propriedades: • um banco de dados é uma coleção lógica coerente de dados com um significado inerente; uma disposição desordenada dos dados não pode ser referenciada como um banco de dados; • um banco de dados é projetado, construído e preenchido com dados para um propósito específico; um banco de dados possui um conjunto pré definido de usuários e aplicações; Rudson Kiyoshi Souza Carvalho Página 5 Administração e Projeto de Banco de Dados • um banco de dados representa algum aspecto do mundo real, o qual é chamado de “mini-mundo” ; qualquer alteração efetuada no mini-mundo é automaticamente refletida no banco de dados. Um banco de dados pode ser criado e mantido por um conjunto de aplicações desenvolvidas especialmente para esta tarefa ou por um “Sistema Gerenciador de Banco de Dados” (SGBD). Um SGBD permite aos usuários criarem e manipularem bancos de dados de propósito gerais. O conjunto formado por um banco de dados mais as aplicações que manipulam o mesmo é chamado de “Sistema de Banco de Dados”. Sistema de Banco de Dados Segundo C. J. Date um sistema de banco de dados é basicamente um sistema computadorizado de manutenção de registros. O banco de dados, por si só, pode ser considerado como o equivalente eletrônico de um armário de arquivamento, ou seja, ele é um repositório ou recipiente para uma coleção de arquivos de dados computadorizados, de modo geral a finalidade de um banco de dados é armazenar informações e permitir que os usuários busquem e atualizem essas informações quando forem requisitadas. As informações em questão podem ser qualquer coisa que tenha um significado ao individuo ou à organização a que o sistema deve servir. Os usuários de um sistema podem realizar (ou melhor, solicitar que o sistema realize) diversas operações envolvendo tais arquivos, como por exemplo: • Acrescentar novos arquivos ao banco de dados • Inserir dados em arquivos existentes • Buscar dados de arquivos existentes • Alterar dados de arquivos existentes • Excluir dados de arquivos existentes • Remover arquivos existentes do banco de dados 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 dados ficam armazenados no banco de dados e só podem ser removidos por uma requisição explícita ao mesmo. Isso difere de outros tipos de dados, como, por exemplo, dados de entrada, dados de saída, filas de trabalho, instruções SQL e quaisquer outros que possuam natureza transitória. Os dados em um sistema de banco de dados são integrados e compartilhados Rudson Kiyoshi Souza Carvalho Página 6 Administração e Projeto de Banco de Dados Por integrado, queremos dizer que o banco de dados pode ser considerado como uma unificação de vários arquivos que, de outro modo, seriam distintos, com a eliminação de qualquer redundância parcial ou total entre esses arquivos. Por compartilhado, queremos dizer que o banco de dados pode ser compartilhado entre diferentes usuários, no sentido de que diferentes usuários podem ter acesso aos mesmos dados, possivelmente ao mesmo tempo (acesso concorrente). Também devemos fazer uma diferenciação entre dado e informação. O dado é aquilo que realmente é armazenado no banco de dados, enquanto a informação refere-se ao significado desses dados para determinado usuário. Por exemplo, se armazenamos no banco de dados a data de nascimento de um cliente como sendo 10/01/1970, esse dado nos da a informação que em 20/12/1990 esse cliente estava com 20 anos. Hardware Os componentes de hardware do sistema de banco de dados consistem em: • Volumes de armazenamento secundário – normalmente discos magnéticos -, que são usados para manter os dados armazenados, juntamente com os dispositivos de E/S (entrada/saída) associados (unidades de disco etc), controladores de dispositivos, canais de E/S e assim por diante. • Processador(es) de hardware e memória principal associada, que são usados para dar suporte à execução do software do sistema de banco de dados. Software Entre o banco de dados físico – ou seja, os dados fisicamente armazenados – e os usuários do sistema existe uma camada de software conhecida como gerenciador de banco de dados, ou mais freqüentemente conhecido SGBD – Sistema Gerenciador de Banco de dados. O SGBD será responsável por tratar todas as requisições citadas anteriormente como acrescentar novos arquivos ao banco de dados ou inserir dados em arquivos existentes etc.. Usuários Os usuários (finais) acessam o banco de dados interativamente através de alguma aplicação ou interface on-line que na maioria das vezes podem ser oferecidas pelo fornecedor do SGBD estas aplicações são internas (built-in), e não escrita pelos usuários, a maior parte dos sistemas possui pelo menos uma aplicação built-in, chamada de processador de linguagem de consulta, por meio do qual o usuário pode emitir requisições ao banco de dados. Consideremos de forma geral quatro classes de usuários que interagem com o banco de dados: Rudson Kiyoshi Souza Carvalho Página 7 Administração e Projeto de Banco de Dados Usuários finais: Existem basicamente três categorias de usuários finais que são os usuários finais do banco de dados, fazendo consultas, atualizações e gerando documentos: • Usuários casuais: acessam o banco de dados casualmente, mas que podem necessitar de diferentes informações a cada acesso; utilizam sofisticadas linguagens de consulta para especificar suas necessidades; • Usuários novatos ou paramétricos: utilizam porções pré-definidas do banco de dados, utilizando consultas pré-estabelecidas que foram exaustivamente testadas; • Usuários sofisticados ou de alto nível: são usuários que estão familiarizados com o banco de dados e realizam consultas complexas (query). Administrador de Banco de Dados (DBA) Em um ambiente de banco de dados, o recurso primário é o banco de dados por si só e o recurso secundário o SGBD e os softwares relacionados. A administração destes recursos cabe ao Administrador de Banco de Dados, o qual é responsável pela autorização de acesso ao banco de dados e pela coordenação e monitoração de seu uso. São tarefas do DBA: • Definição da estrutura de armazenamento e a estratégia (ou método) de acesso. • Concessão de autorização para acesso a dados. • Definição de controles de integridade. • Definição de estratégias para cópia de segurança e recuperação. • Monitoramento do desempenho. • Execução de rotinas de desempenho. • Modificação da organização física. Projetista de Banco de Dados (Administrador de Dados) O Projetista de Banco de Dados é responsável pela identificação dos dados que devem ser armazenados no banco de dados, escolhendo a estrutura correta para representar e armazenar dados.Muitas vezes, os projetistas de banco de dados atuam como “staff” do DBA, assumindo outras responsabilidades após a construção do banco de dados. É função do projetista também avaliar as necessidades de cada grupo de usuários para definir as visões que serão necessárias, integrando-as, fazendo com que o banco de dados seja capaz de atender a todas as necessidades dos usuários. São tarefas do AD: Definição e atualização do esquema do banco de dados. Analistas de Sistemas e Programadores de Aplicações Os analistas determinam os requisitos dos usuários finais e desenvolvem especificações para transações que atendam estes requisitos, e os programadores são os responsáveis pelo desenvolvimento de aplicações em linguagens como Java, Cobol, C#, C++, VB.net e etc. que fazem chamadas ou requisições ao SGBD através de instruções SQL Rudson Kiyoshi Souza Carvalho Página 8 Administração e Projeto de Banco de Dados Por que um Sistema de Banco de Dados? As vantagens de um sistema de banco de dados em relação aos métodos tradicionais, baseados em papel são muitas, como por exemplo: • Densidade: Não há a necessidade de arquivos de papel, possivelmente volumosos. • Velocidade: A máquina pode obter e atualizar dados com uma velocidade muito maior do que o ser humano. • Atualidade: Informações precisas e atualizadas estão disponíveis a qualquer momento sob consulta. • Proteção: Os dados podem ser bem protegidos contra a perda não intencional e acesso ilegal. Vantagens tecnológicas da utilização de um Sistema de Banco de Dados • Controle de Redundância A redundância consiste no armazenamento de uma mesma informação em locais diferentes, provocando inconsistências. Em um Banco de Dados as informações só se encontram armazenadas em um único local, não existindo duplicação descontrolada dos dados. • Compartilhamento de Dados Um banco de dados multiusuário deve permitir que múltiplos usuários acessem o banco de dados ao mesmo tempo. Este fator é essencial para que múltiplas aplicações integradas possam acessar o banco. O banco de dados multiusuário deve manter o controle de concorrência para assegurar que o resultado de atualizações seja correto. Um banco de dados multiusuário deve fornecer recursos para a construção de múltiplas visões. • Restrição a Acesso não Autorizado O banco de dados deve dispor de recursos que possibilitem selecionar a autoridade de cada usuário. Assim um usuário poderá realizar qualquer tipo de acesso, outros poderão ler alguns dados e atualizar outros e outros ainda poderão somente acessar um conjunto restrito de dados para escrita e leitura. • Tolerância a Falhas Um banco de dados deve fornecer recursos para recuperação de falhas tanto de software quanto de hardware. • Integridade Um banco de dados deverá impedir que aplicações ou acessos pelas interfaces possam comprometer a integridade dos dados. Rudson Kiyoshi Souza Carvalho Página 9 Administração e Projeto de Banco de 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 geral envolvendo diversas operações de banco de dados, onde uma operação só pode ser validada pelo banco de dados se todas as demais operações da transação também o forem. Exemplo: Transação bancária de transferência de dinheiro. A transação só pode ser validada se as operações de débito em uma conta origem e crédito em uma conta destino forem validados. Quando não Utilizar um SGBD Em algumas situações, o uso de um SGBD pode representar uma carga desnecessária aos custos quando comparado à abordagem processamento tradicional de arquivos como, por exemplo: • Alto investimento inicial na compra de software e hardware adicionais; • Generalidade que um SGBD fornece na definição e processamento de dados; • Sobrecarga na provisão de controle de segurança, controle de concorrência, recuperação e integração de funções. • Problemas adicionais podem surgir caso os projetistas de banco de dados ou os administradores de banco de dados não elaborem os projetos corretamente ou se as aplicações não são implementadas de forma apropriada. Se o DBA não administrar o banco de dados de forma apropriada, tanto a segurança quanto a integridade dos sistemas podem ser comprometidas. A sobrecarga causada pelo uso de um SGBD e a má administração justificam a utilização da abordagem processamento tradicional de arquivos em casos como: • O banco de dados e as aplicações são simples, bem definidas e não se espera mudanças no projeto; • A necessidade de processamento em tempo real de certas aplicações, que são terrivelmente prejudicadas pela sobrecarga causada pelo uso de um SGBD; • Não haverá múltiplo acesso ao banco de dados. Rudson Kiyoshi Souza Carvalho Página 10 Administração e Projeto de 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 do Study Group on Data Base Management Systems para representar os sistemas de banco de dados. A meta desta arquitetura é separar as aplicações de usuários da base de dados física. Nessa arquitetura a base de dados pode ser definida em três níveis: Nível Externo, Nível Conceitual e Nível Interno ou Físico. Os três níveis da arquitetura: • O nível externo ou visão (também conhecido como nível lógico de usuário) é o mais próximo dos usuários, ou seja, é aquele que se ocupa de como os dados são vistos por usuários individuais, como os dados estão organizados para formar a informação para cada usuário. O nível externo possui esquemas externos ou visões e não depende do sistema gerenciador de banco de dados. Cada esquema descreve a visão da informação de um grupo de usuários. Cada visão descreve, tipicamente, à parte da base de dados que um particular grupo de usuários está interessado e esconde o resto da base de dados do mesmo. • O nível conceitual (também conhecido como nível lógico de comunidade, ou as vezes apenas como nível lógico, sem qualificação) possuí um esquema conceitual que representa a estrutura da base de dados que é o produto da normalização. È uma visão mais apropriada para os projetistas onde todos os conjuntos de dados do nível externo estão quebrados em pedaços lógicos, fundidos para reduzir repetição, e estruturados para eliminar dependências. O esquema conceitual é uma descrição global da base de dados, que omite detalhes da estrutura de armazenamento físico e se concentra na descrição de entidades, tipos de dados, relacionamento e restrições (Diagrama de Entidade e Relacionamento). • O nível Interno ou Físico (também conhecido como nível de armazenamento) é o mais próximo do meio de armazenamento físico, ou seja, é aquele que se ocupa do modo como os dados, ou melhor, registros e arquivos são fisicamente armazenados dentro da base de dados e depende fortemente do SGBD selecionado. É uma visão mais apropriada aos programadores de base de dados. Todos os conjuntos de dados do nível físico estão organizados para aperfeiçoar a velocidade de execução, maximizar a disponibilidade dos dados, e manter os dados seguros. Rudson Kiyoshi Souza Carvalho Página 11 Administração e Projeto de Banco de Dados Figura 2 Os três níveis da arquitetura. Analisando a imagem podemos observar que o nível externo se preocupa com as percepções dos usuários individuais, enquanto o nível conceitual está preocupado com uma percepção da comunidade de usuários. Na maioria dos casos alguns usuários não terão acesso a toda informação do banco de dados, mas somente acessarão algumas partes das informações contidas no mesmo; assim, haverámuitas “visões externas” distintas, cada qual consistindo em uma representação abstrata de alguma parte da informação contida no banco de dados, e haverá uma “visão conceitual”, consistindo em uma representação igualmente abstrata do banco de dados em sua totalidade. Do mesmo modo haverá uma “visão interna”, representando o modo como os dados estão armazenados internamente. 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ível superior (figura anterior). Existem dois tipos de independência de dados: • Independência de dados lógica: é a capacidade de alterar o esquema conceitual sem ter que alterar o esquema externo ou as aplicações do usuário, ou seja, podemos alterar o esquema conceitual sem a necessidade de reescrever os programas aplicativos. Algumas vezes é necessário alterar a estrutura lógica do banco de dados como por exemplo adicionando alguma nova entidade (tabela) ao banco. • Independência de dados física: é a capacidade de alterar o esquema interno sem ter que alterar o esquema conceitual, o esquema externo ou as aplicações do usuário, ou seja, podemos alterar o esquema físico sem Rudson Kiyoshi Souza Carvalho Página 12 Administração e Projeto de Banco de Dados a necessidade de reescrever os programas aplicativos. Algumas vezes são necessárias modificações no nível físico para melhorar o desempenho. Sistema de Gerenciamento de Bancos de Dados (SGBD) Um sistema gerenciador de banco de dados (SGBD) é responsável por armazenar dados de forma confiável e permitir fácil recuperação e atualização desses dados. Um SGBD relacional (SGBDR ou RDBMS relational database management system) armazena dados de forma relacional, isto é na forma de linhas e colunas. A seqüência abaixo ilustra o papel do sistema de gerência de banco de dados, de forma conceitual: 1. O usuário emite uma solicitação de acesso. 2. O SGBD intercepta a solicitação e a analisa. 3. O SGBD inspeciona os esquemas externos (ou sub-esquemas) relacionados àquele usuário, os mapeamentos entre os três níveis, e a definição da estrutura de armazenamento. 4. O SGBD realiza as operações solicitadas no banco de dados armazenado. Exemplos de SGBD: Oracle, Microsoft SQL Server. IBM DB2, SyBase, Paradox, Progress, MySql, Microsoft Access etc. 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 sistema operacional do computador fornece apenas os serviços mais básicos e o sistema de banco de dados precisa ser construído sobre essa base. Portanto, o projeto do sistema de banco de dados precisa incluir considerações sobre a interface entre o sistema de banco de dados e o sistema operacional. Os componentes funcionais de um sistema de banco de dados incluem: • Gerenciador de arquivos, que gerencia a alocação do espaço na armazenagem do disco e as estruturas de dados usadas para representar a informação armazenada no disco. • Gerenciador do banco de dados, que fornece a interface entre os dados de baixo nível armazenados no disco e os programas aplicativos e de consulta submetidos ao sistema. Rudson Kiyoshi Souza Carvalho Página 13 Administração e Projeto de Banco de Dados • Processador de consultas, que traduz os comandos numa linguagem de consulta para instruções de baixo nível que o gerenciador do banco de dados pode interpretar. Além disso, o processador de consultas tenta transformar uma requisição do usuário em uma forma compatível e mais eficiente com respeito ao banco de dados, encontrando uma boa estratégia para executar a consulta. • Pré-compilador da DML, que converte comandos da DML embutidos em um aplicativo para chamadas de procedimento normal na linguagem hospedeira. O pré-compilador precisa interagir com o processador de consultas pra gerar o código apropriado. • Compilador da DDL, que converte comandos da DDL em um conjunto de tabelas contendo metadados ou "dados sobre dados". Adicionalmente, diversas estruturas de dados são requeridas como parte da implementação do sistema físico, incluindo: • Arquivos de dados, que armazenam o banco de dados propriamente dito. • Dicionário de dados, que armazena metadados sobre a estrutura do banco de dados. O dicionário de dados é usado com freqüência. Assim, deve-se dar grande ênfase no desenvolvimento de um bom projeto e implementação eficiente do dicionário. • Índices, que fornecem acesso rápido aos itens de dados guardando determinados valores. Estrutura básica de um sistema gerenciador de Banco de dados Figura 3 Estrutura básica de um SGBD Rudson Kiyoshi Souza Carvalho Página 14 Administração e Projeto de Banco de Dados Visão expandida da arquitetura do sistema de banco de dados Figura 4 Estrutura expandida de um SGBD Rudson Kiyoshi Souza Carvalho Página 15 Administração e Projeto de Banco de Dados Linguagens para Manipulação de Dados Quando tratamos de banco de dados, e desejamos criar uma estrutura lógica para armazenamento e organização destes dados e realizar consultas, alterações, restrições de acesso, definições de esquemas e etc, fazemos uso de uma linguagem que nos auxilie e facilite realizar esta tarefa. As Linguagens para Manipulação de Dados são divididas em três grupos de comandos: • DDL (Data Definition Language - Linguagem de Definição de Dados) Para a criação dos objetos do banco de dados (tabelas, índices, relacionamentos, visões etc) utilizamos a linguagem DDL (Data Definition Language - Linguagem de Definição de Dados). O SGBD possui um compilador DDL que permite a execução das declarações para identificar as descrições dos esquemas e para armazená-las no catálogo do SGBD. • DML (Data Manipulation Language - Linguagem de Manipulação de Dados) Uma vez que o banco de dados esteja criado, usa-se uma linguagem para fazer a manipulação dos dados (ler, inserir, alterar e excluir), a DML (Data Manipulation Language - Linguagem de Manipulação de Dados). • DCL (Data Control Language) Linguagem de Controle de Dados – Utilizada para tratar as permissões do banco de dados como a concessão (GRANT) ou revogação (REVOKE) de privilégios no banco de dados. Rudson Kiyoshi Souza Carvalho Página 16 Administração e Projeto de Banco de Dados Modelos de Bancos de Dados Existem diversos modelos de banco de dados, e cada modelo tem suas características de manipulação e armazenamento dos dados, dentre estes modelos vamos conhecer os quatro principais e mais comuns modelos encontrados no mercado, são eles: o modelo hierárquico, em rede, relacional e orientado a objetos. Para explicarmos cada modelo, iremos utilizar as informações da tabela abaixo: Nome Município Estado Conta Saldo João SBC SP A102 400,00 Ana SP SP A101 500,00 A202 900,00 Pedro Osasco SP A305 350,00 O Modelo Hierárquico O modelo hierárquico é uma coleção 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 coleção de campos (atributos), cada qual contendo somente um valor. Um link é uma associação entre exatamente dois registros. Portanto, um link pode ser visto como uma forma restrita (binária) de relacionamento no sentido do modelo entidade x relacionamento. Este modelo utiliza árvores para a representação lógica dos dados. Esta árvore estacomposta 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), por isso apresenta vários inconvenientes como: • Não se admitem relações N:M (muitos para muitos) • Um segmento filho não pode ter mais de um pai. • Não se permitem mais de uma relação entre dois segmentos. • Para acessar a qualquer segmento é necessário começar pelo segmento raiz • A árvore se deve percorrer na ordem designada. Rudson Kiyoshi Souza Carvalho Página 17 Administração e Projeto de Banco de Dados 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 uma entidade do modelo entidade x relacionamento. Cada registro é uma coleção de campos (atributos), cada qual contendo somente um valor. Um link é uma associação entre exatamente dois registros. Portanto, um link pode ser visto como uma forma restrita (binária) de relacionamento no sentido do modelo entidade x relacionamento. Nesta estrutura qualquer componente pode se relacionar com qualquer outro. Diferentemente do modelo hierárquico, neste modelo, 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) Rudson Kiyoshi Souza Carvalho Página 18 Administração e Projeto de Banco de Dados O Modelo Relacional O Modelo Relacional de banco de dados é o modelo no qual iremos nos aprofundar nesse curso, por ser um modelo de fácil entendimento e o mais utilizado atualmente. Ele representa os dados por meio de conceitos matemáticos da teoria dos conjuntos. Dirigido, este modelo foi proposto pelo pesquisador Edgar Ted Frank Codd em jun/1970, este modelo melhora a visão dos dados, a abordagem relacional faz com que o banco de dados seja representado como um conjunto de tabelas bidimensionais, originadas em linhas e colunas. A relação entre duas tabelas é feita através de colunas em comum (chave primária e chave estrangeira). Figura 7 Banco de Dados Relacional Algumas de suas principais características são: • Pode ser entendido e usado por qualquer usuário. • Permite ampliar o esquema conceitual sem modificar as aplicações de gerenciamento. • Os usuários não necessitam saber onde se encontram os dados fisicamente. O elemento principal deste modelo é a relação que se representa mediante uma tabela. Exemplo de banco de dados Relacional: Oracle, DB2(IBM), MySql (MySql AB), Firebird (Open Source), PostgreSQL (Open Source), SQL Server (Microsoft),Sybase Adaptative Server (Sybase) Rudson Kiyoshi Souza Carvalho Página 19 Administração e Projeto de Banco de Dados 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 objetos continuam a existir mesmo após o encerramento do programa. Através das construções orientadas a objeto, os programadores podem esconder os detalhes da implementação de seus módulos, compartilhar a referência a objetos e expandir seus sistemas através de módulos existentes. A funcionalidade de banco de dados é necessária para assegurar o compartilhamento concomitante e a continuidade das informações nas aplicações. Através dos bancos de dados os programadores podem obter o estado em que os objetos se encontram, e estar atualizados entre várias solicitações do programa, e vários usuários podem ao mesmo tempo compartilhar a mesma informação. O banco de dados orientado a objeto combina os benefícios e conceitos da orientação a objetos com 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 que recebem as características de seus supertipos. • O acesso aos dados pode ser rápido porque as junções geralmente não são necessárias. Exemplo de banco de dados OO: CACHÉ, VERSANT, DB4Objects, O2, GEMSTONE, JASMINE, MATISSE, Objectivity/DB, Ozone. Rudson Kiyoshi Souza Carvalho Página 20 Administração e Projeto de Banco de Dados Modelagem de Dados Para começarmos a tratar de modelagem de dados, vamos primeiramente definir modelo. Modelo: é a representação abstrata e simplificada de um sistema real, com a qual se pode explicar ou testar o seu comportamento, em seu todo ou em partes. “Temos que modelar o mundo observado, seja ele real ou imaginário. Paulo Cougo” O processo de modelagem de um banco de dados é dividido em três etapas: • Modelo Conceitual • Modelo Lógico • Modelo Físico Modelo Conceitual de Dados (MCD) O Modelo Conceitual representa e/ou descreve a realidade do ambiente observado, constituindo-se em uma visão global dos principais dados e relacionamentos (estruturas de informação), independente das restrições de implementação impostas por tecnologias, técnicas de implementação ou dispositivos físicos, ou seja, na etapa de elaboração do modelo conceitual, pouco importa se o sistema escolhido será um SGBD Relacional, de Rede ou Hierárquico. Quando se fala em Modelo Conceitual, estamos nos referindo a primeira etapa do projeto de um sistema de aplicação em banco de dados, ele deve ser utilizado para o nível de conversação, entendimento, transmissão, validação de conceitos, mapeamento do ambiente etc... O objetivo do Modelo Conceitual é descrever as informações contidas em uma realidade, as quais irão estar armazenadas em um banco de dados. É uma descrição em alto nível (macro-definição), mas que tem a preocupação de captar e retratar toda a realidade de uma organização, setor, repartição, departamento, negócio etc. Como dizemos no inicio deste tópico, o Modelo Conceitual não retrata os aspectos ligados à abordagem do banco de dados que será utilizado e tão pouco se preocupa com as formas de acesso ou estruturas físicas implementadas por um SGBD (Sistema Gerenciador de Banco de Dados) específico. O resultado de um Modelo Conceitual é um esquema que representa a realidade das informações existentes, assim como as estruturas de dados que representam estas informações. Rudson Kiyoshi Souza Carvalho Página 21 Administração e Projeto de Banco de Dados Modelo Lógico de Dados (MLD) Defini-se como modelo lógico de dados aquele em que os objetos, suas características e relacionamentos têm a representação de acordo com as regras de implementação e limitantes impostos por algum tipo de tecnologia. O Modelo Lógico tem o seu início a partir do Modelo Conceitual, levando em consideração a abordagem de rede, hierárquica, relacional ou orientada a objeto, esse modelo deve ser elaborado respeitando-se e implementando-se conceitos tais como chaves de acesso, controles de chaves duplicadas, normalização, ponteiros, headers, integridade referencial, entre outros. Estas são preocupações e necessidades somente relevantesao Modelo Lógico, jamais devem ser levadas ao Modelo conceitual. O Modelo Lógico descreve as estruturas que estarão contidas no banco de dados, de acordo com as possibilidades permitidas pela abordagem, mas sem considerar, ainda, nenhuma característica específica de um Sistema Gerenciador de Banco de Dados (SGBD), resultando em um esquema lógico de dados sob a ótica de uma das abordagens citadas. Modelo Físico de Dados (MFD) O Modelo Físico irá partir do Modelo Lógico e descreve as estruturas físicas de armazenamento de dados, tais como: tamanho de campos, índices, tipo de preenchimento destes campos, nomenclaturas, etc. Será projetado de acordo com os requisitos de processamento e uso mais econômico dos recursos computacionais. Este modelo detalha o estudo dos métodos de acesso ao SGBD, para elaboração dos índices de cada informação colocada nos Modelos Conceituais e Lógicos. Cada empresa fornecedora do SGBD poderá definir um diferente modo de implementação física das características e recursos necessários para o armazenamento e manipulação das estruturas de dados Esta é a etapa final do projeto de Banco de Dados, na qual será utilizada a Linguagem de Definição de Dados do SGBD (DDL), para a criação física do banco de dados proposto. 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 uma possível abordagem para o processo de modelagem dos dados. Esse trabalho, após sua divulgação e ampla aceitação, passou a ser considerado como um referencial definitivo para o processo de modelagem de dados. A abordagem entidade-relacionamento é composta de uma técnica de diagramação e de um conjunto de conceitos que devem ser entendidos e respeitados. O modelo entidade-relacionamento é um modelo de dados conceitual de alto nível, cujos conceitos foram projetados para estar o mais próximo possível da visão que o usuário tem dos dados, não se preocupando em representar como estes dados estarão realmente armazenados. O modelo ER é utilizado principalmente durante o processo de projeto de banco de dados. Rudson Kiyoshi Souza Carvalho Página 22 Administração e Projeto de Banco de Dados O modelo ER utiliza, basicamente, os retângulos para representar as entidades, losangos para representar os relacionamentos, elipses (balões) para indicar e alocar os atributos, linhas que unem os atributos aos conjuntos de entidades e os conjuntos de entidades aos relacionamentos, elipses duplas que representam os relacionamentos multivalorados e linhas duplas que indicam participação total de uma entidade em um conjunto de relacionamentos. O diagrama ER fornece uma visão lógica do banco de dados, fornecendo um conceito mais generalizado de como estão estruturados os dados de um sistema. Os objetos que compõem o diagrama ER estão listados a seguir, na figura abaixo: Rudson Kiyoshi Souza Carvalho Página 23 Administração e Projeto de Banco de Dados 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 uma identificação distinta e um significado próprio, ou seja, é todo objeto concreto ou abstrato que tem existência própria, quando considerado o âmbito de um negócio. São coisas sobre as quais desejamos arquivar informações. São as “coisas” que existem no negócio, ou ainda, descrevem o negócio em si. A entidade é representada por um retângulo, conforme as figuras abaixo: Em um universo observado, estaremos reconhecendo objetos (coisas). Estes objetos estarão sendo percebidos como elementos individualizados, mas, ao mesmo tempo, poderão ser enquadrados em um conjunto ou categoria em função de suas semelhanças, estes objetos neste processo de observação serão as entidades, vejamos um exemplo: 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ças produzidas. • Máquinas recuperadoras de peças. • Funcionários responsáveis pela verificação da qualidade das peças. • Peças produzidas nos mais diversos formatos. Dentre esses elementos observados, poderemos perceber a existência de vários conjuntos distintos de elementos (entidades), entre eles: • Máquina – que representa todas as máquinas observadas. • Funcionário – que representa todos os funcionários. • Ferramenta – que representa todas as ferramentas. • Peças – que representará todos os tipos de peças produzidas. Rudson Kiyoshi Souza Carvalho Página 24 Cliente Fornecedor Pedido Aluno Administração e Projeto de Banco de Dados Atributo É uma informação que caracteriza uma entidade ou um relacionamento. Toda entidade possui atributos, mas nem todo relacionamento é caracterizado por atributos. Os atributos podem ser classificados em: Descritivo, Identificador, Composto, Derivado e Multivalorado. 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 único atributo. Derivado: Pode ter um valor que é derivável de valores de outros atributos. Multivalorado: Pode ser preenchido com muitos valores. Rudson Kiyoshi Souza Carvalho Página 25 AtributoDescritivo AtributoIdentificador AtributoComposto Agregad o agregad o Agregad o AtributoDerivado Nome- atributo AtributoMultivalorado Administração e Projeto de Banco de Dados Exemplo de uma entidade e seus diferentes tipos de atributos: Relacionamento É a ligação entre duas ou mais entidades. Ao observarmos os objetos e reconhecê-los, estaremos quase que imediatamente, reconhecendo as relações existentes entre eles. Muitas vezes a própria observação de um relacionamento será o ponto de partida para a identificação dos objetos que dele participam. O que estabelecerá associações válidas ou não será simplesmente o grau de fidelidade e completeza que consigamos atingir durante o processo de modelagem. O relacionamento é representado por um losango. Exemplo: Assim, se desejarmos ter, conceitualmente, representado um ambiente observado onde “Anderson é proprietário de um jipe amarelo”, podemos segui a seguinte estratégia: 1. Identificar os objetos envolvidos (entidades): Pessoa (Anderson) Carro (Jipe Amarelo) 2. Caracterizar os objetos (atributos): Pessoa (nome, data nascimento, número CPF e etc.) Carro (marca, cor, ano de fabricação, modelo etc.) 3. Representar os objetos: 4. Identificar o relacionamento entre os objetos: Rudson Kiyoshi Souza Carvalho Página 26 Rua Número Bairro Cidade Endereço Idade AlunoData Nasc. RA Data Nasc.Telefones Aluno Disciplina Freqüen ta Pessoa Carro Administração e Projeto de Banco de Dados 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 de ocorrências de uma entidade que está associado a ocorrências de outra entidade determina o Grau do Relacionamento ou Cardinalidade deste fato. Quando questionamos se um homem poderia estar casado com mais de uma mulher, estamos na realidade questionando o grau de relacionamento que existe entre as entidades Homem e Mulher. Em modelagem, ao se tratar de relacionamentos, podemos apresentar os mesmos através de três possibilidades:• Um-para-Um (1:1) • Um-para-Muitos (1:N) • Muitos-para-Muitos (N:N) ou (M:N) É o grau de ligação entre as entidades. É representada por “0”, “1” ou “N”, significando “zero”, “um” ou “muitos” respectivamente. Forma de leitura Entidade – Relacionamento – Cardinalidade – Entidade. A leitura deve ser feita em ambas as direções. 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 Rudson Kiyoshi Souza Carvalho Página 27 1,11,1 Curso CoordenadorCoorden a mínimo máximo Pessoa Carro É Proprietári a Marido Esposa Casado 1 1 Administração e Projeto de Banco de Dados 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 uma dada empresa não poderá ser de nenhuma outra. Cardinalidade Mínima e Máxima Um vendedor atende zero ou uma região. Uma região é atendida por zero ou muitos vendedores. Rudson Kiyoshi Souza Carvalho Página 28 0,10,N Vendedor RegiãoAtend e PD Têxtil Eletrônica Douglas Pedro Ana Campinas Piracicaba Sorocaba Mário Carla João Ana Empresa FilialPossui 1 N Administração e Projeto de Banco de Dados Relacionamento Muitos-para-Muitos (N:N) Pois certo livro pode ser escrito pó um conjunto de autores (3, por exemplo), e, por sua vez, cada um dos autores pode escrever mais de um livro. Cardinalidade Mínima e Máxima Um fornecedor fornece zero ou muitos produtos. Um produto é fornecido por zero ou muitos fornecedores. Rudson Kiyoshi Souza Carvalho Página 29 W X Y Z A B C D E 0.N0.N Fornecedor ProdutoForne ce Livro AutorEscrit o N N Administração e Projeto de Banco de Dados Participação Outra restrição muito importante é a participação. A participação define a existência de uma entidade através do relacionamento, podendo ser parcial ou total. Veja um exemplo. A participação do empregado é parcial, pois nem todo empregado gerencia um departamento, porém a participação do departamento neste relacionamento é total, pois todo departamento precisa ser gerenciado por um empregado. Desta forma, todas as entidades do tipo DEPARTAMENTO precisam participar do relacionamento, mas nem todas as entidade do tipo entidade EMPREGADO precisam participar do relacionamento. Estas restrições são chamadas de restrições estruturais. Rudson Kiyoshi Souza Carvalho Página 30 RH Projetos Compras Luiz Paula Pedro Moacir Fernanda Maria José Empregado Gerencia Departamento Empregado Departamento Gerenc ia Administração e Projeto de Banco de Dados 1.1.1 Considerações sobre Entidades Fortes e Entidades Fracas Alguns autores adotam, para fins de caracterização de uma entidade, um critério que as classifica em fortes (regulares) ou fracas. Onde uma entidade fraca é uma entidade cuja existência depende de alguma outra entidade, no sentido de que ela, não poder existir se essa outra entidade também não existir. Esta caracterização se dá através da analise de existência de duas condições básicas: • Dependência de existência. Se uma entidade B depender de uma entidade A para existir, teremos em B uma entidade fraca, enquanto que A, se não depender de ninguém para existir, será considerada uma entidade forte. • Dependência de identificador. Se uma entidade não possui atributos suficientes para formar uma chave primária, este tipo de entidade é considerado uma entidade fraca. Do ponto de vista de modelagem conceitual, assim como a dependência de existência este tipo de critério pode ser visto como dispensável, pois sua importância será reconhecida sob o ponto de vista de projeto lógico, onde as chaves identificadoras, utilizadas como diferenciadores entre instâncias dos elementos, ou como método de endereçamento de registro, passam a ter papel vital durante a o processo de estrutura de dados. A relação entre um entidade forte e uma fraca deve ser 1:N. Por exemplo, em um modelo de cadastro de funcionários, poderíamos ter a entidade “Empregado” e para este empregado uma entidade “Dependente”, os dependentes de um empregado, poderiam ser classificados como entidades fracas, pois os dependentes não poderiam existir sem um empregado não fosse cadastrado. Em particular se algum empregado for excluído, todos os seus dependentes também devem ser excluídos. Um conjunto de entidades fracas é identificado no modelo E-R pela linha dupla usada no retângulo e no losango do relacionamento correspondente. No diagrama abaixo, o conjunto de entidades fracas pagamento é dependente do conjunto de entidades fortes Empréstimo pelo conjunto de relacionamento pagamento_empréstimo. A figura também apresenta o uso de linhas duplas para identificar participação total – a participação do conjunto de entidades (fracas) pagamento no relacionamento pagamento_empréstimo é total, significando que todo o pagamento precisa estar relacionado via pagamento_empréstimo a alguma conta. Rudson Kiyoshi Souza Carvalho Página 31 Administração e Projeto de Banco de Dados Relacionamentos Reflexivos (auto-relacionamento) São os relacionamentos que ocorrem entre as ocorrências de uma mesma entidade. Normalmente eles representam algum tipo de hierarquia. Funcionário gerencia 0 ou muitos funcionários. Funcionário é gerenciado por um único funcionário. Extensões do Modelo Entidade x Relacionamento O modelo de dados Entidade x Relacionamentos, como proposto por Peter Chen, tem sido usado efetivamente para a comunicação do usuário final, apresentando entidades e relacionamentos. Entretanto, quando usado para integrar diferentes modelos conceituais com diferentes usuários finais, fica severamente limitado até que se utilize um conceito de abstração de dados denominado generalização. Relacionamentos entre Múltiplas Entidades Até o momento analisamos apenas situações em que as entidades se relacionam sozinhas ou em pares, este é o principio da descoberta de relacionamentos, a analise de relacionamento em pares, no entanto um relacionamento pode envolver mais de duas entidades, que podem ser três, quatro, cinco ou uma quantidade indeterminada. Rudson Kiyoshi Souza Carvalho Página 32 1,1 0,N Funcionário Gerenci a Empréstimo Pagamento Pagamento_E mpréstimo Número_empréstimo Total Data_Pagt o Número_pagamento Total_pagto Pagamento_empr éstimo Administração e Projeto de Banco de Dados Os relacionamentos entre múltiplas entidades expressam um fato em que todas as entidades ocorrem simultaneamente, ou seja, todas as ocorrências do relacionamento possuem, sempre, ligações com todas as entidades envolvidas no relacionamento. Não é possível um relacionamento triplo (Ternário), em um determinado momento, transformar-se em duplo (Binário). O diagrama abaixo representa uma situação de relacionamento que envolve três entidades simultaneamente, a este tipo de relacionamento triplo, damos o nome de Relacionamento Ternário. Um técnico que atua em um projeto utiliza um notebook. Um notebook é utilizado em um projeto por um técnico. Um técnico com um notebook atua em um projeto. Entidade associativa Um relacionamento é uma associação entre entidades. Na modelagem ER não foi prevista a possibilidade de associar dois relacionamentos entre si. Na pratica, quando estamos construindo um novo modelo ER ou modificando um modelo ER existente, surgem situações em que é desejável permitir a associação de uma entidade a um relacionamento. Vejamos um exemplo: Suponha que seja necessário modificar este relacionamento da seguinte forma. É necessário saber que medicamentos existem e que medicamentos foramprescritos em cada consulta. Para saber que medicamentos existem, cria-se uma nova entidade, Medicamento. A questão agora é: com que entidade existente deve estar relacionada a nova entidade? Se Medicamento fosse relacionado a Médico, ter-se-ia apenas a informação de que médico prescreveu que medicamentos, faltando a informação do paciente que os teve prescritos. Por outro lado, Rudson Kiyoshi Souza Carvalho Página 33 Técnico Projetoatu a 11 1 Notebook NN Médico PacienteConsult a Administração e Projeto de Banco de Dados se Medicamento fosse relacionado à Paciente, faltaria a informação do Médico que prescreveu o medicamento. Assim, deseja-se relacionar a prescrição do Medicamento à consulta, ou seja, deseja-se relacionar um relacionamento prescrição com da entidade (Medicamento) a um relacionamento (Consulta), o que não está previsto na abordagem ER. Para tal, foi criado um conceito especial, o de entidade associativa. Uma entidade associativa nada mais é que a redefinição de um relacionamento, que passa a ser tratado como se fosse também uma entidade. Graficamente isso é feito como mostrado na figura abaixo. O retângulo desenhado ao redor do relacionamento Consulta indica que este relacionamento passa a ser visto como uma entidade (associativa, já que é baseada em um relacionamento). Sendo Consulta também uma entidade, é possível associa-l através de relacionamentos a outras entidades, conforme a figura apresentada acima. Agregação O termo agregação tem sido utilizado pelas técnicas de modelagem de sistemas nos mais variados conceitos, porém o conceito lançado em Modelagem de Dados refere-se à visão de um relacionamento como um bloco, como alguma coisa que se relaciona com outra, Isso equivale dizer que um relacionamento esta relacionado a outro. Mas, conceitualmente, não existem relacionamentos entre relacionamentos; é uma inverdade conceitual. Para que exista o relacionamento de uma agregação com outra entidade é necessária a existência de dependência entre os fatos, ou seja, um fato somente acontece após a existência do primeiro fato. Rudson Kiyoshi Souza Carvalho Página 34 NN Médico PacienteConsult a Medicamento Prescrição N N Administração e Projeto de Banco de Dados No diagrama abaixo o Serviço só será utilizado quando um cliente se hospedar em um quarto, o relacionamento utiliza depende do relacionamento de hospeda-se. Generalização (Supertipos) e Especialização (Subtipos) Quando estamos em busca da visualização dos dados de um negócio, é importante atentar ao nível de abstração em que estamos atuando, pois quando definimos uma entidade, estamos com a visão de uma classe genérica de dados que pode estar incorporando, diversas outras classes de dados. Generalização Ao buscarmos as entidades presentes em um dado negócio, pode ser realizado de modo bottom-up (baixo para cima), no qual podemos reconhecer vários conjuntos de entidades com atributos em comum, então, estes atributos comuns são sintetizados em um conjunto de entidades de alto nível. Por exemplo, ao modelarmos um sistema hospitalar, podemos encontrar entidades como Pediatra, Neurologista, Cardiologista, Clínico Geral, entre outros, e ao analisarmos as características de cada entidade, podemos perceber atributos em comum como nome, sexo, data nascimento e tratando tais entidades de forma mais genérica, podemos concluir que todas estas pessoas são médicos. Dentro do contexto de modelagem botton-up, alguns autores classificam a entidade generalizada “médico” como um supertipo. Rudson Kiyoshi Souza Carvalho Página 35 N N N N Cliente Quarto Hospeda- se Serviços Utiliza Administração e Projeto de Banco de Dados Então podemos ter como regra que ao encontrar um conjunto de entidades que possuem o mesmo conjunto de atributos para descrevê-las, podemos generalizá-las em uma única entidade, mantendo sua identidade de subconjunto pela inserção de um atributo qualificador para as ocorrências de cada uma. Especialização A especialização é justamente o inverso da generalização que é o processo de analise botton-up (de baixo para cima) tratado, ao tratarmos da especialização, nos ocorre o processo inverso de análise o processo top-down (de cima para baixo) que é o caso da especialização, ou seja, um conjunto de entidades pode conter subgrupos (subtipos) de entidades que são de alguma forma, diferentes de outras entidades do conjunto, continuando com o exemplo do digrama anterior, ao analisarmos nossa entidade a partir de médico, pode-se reconhecer subgrupos (subtipos) de médico, como Pediatra, Neurologista, Cardiologista, Clínico Geral, entre outros. Generalização X Especialização Na pratica, a generalização é o inverso da especialização. No processo de modelagem novos níveis de representação serão, diferenciadas (especialização) ou sintetizadas (generalização). Generalização Especialização Médico Pediatra, Neurologista, Cardiologista, Clínico Geral Rudson Kiyoshi Souza Carvalho Página 36 Médico Pediatra Neurologista Clínico Geral Cardiologista Administração e Projeto de Banco de Dados Bancos de Dados Relacionais Definição Foi criado por Edgar F. Codd na década de 70. A abordagem relacional está baseada no princípio de que as informações em uma base de dados podem ser consideradas como relações matemáticas e que estão representadas de maneira uniforme, através do uso de tabelas bidimensionais. Este princípio coloca os dados (entidades e relacionamentos) dirigidos para estruturas mais simples de armazenar dados, que são as tabelas, e nas quais a visão do usuário é privilegiada. A grande diferença existente quando se trabalha com bancos de dados relacionais em relação aos ambientes tradicionais, pode ser exemplificada da seguinte forma: Em um ambiente tradicional, a função de acender um fósforo seria descrita de forma exatamente procedural, passo a passo: • Abrir a caixa de fósforos. • Verificar se existem palitos. • Levar o palito à lateral da caixa. • Riscar o palito. • Testar se acendeu ou não. • Etc. Em um ambiente de banco de dados relacional devemos mentalizar que as instruções todas se resumem em uma única, uma operação realizada em conjunto. ACENDA UM FÓSFORO Para definir e explicar claramente suponhamos que queremos retirar de uma sala de aula todos os alunos que possuem média abaixo de 5 pontos. Em um ambiente tradicional seria perguntado a cada aluno: • Sua média é abaixo de 5 ? Se a resposta for sim, pediríamos que saísse. Se fosse não, ele ficaria. Em um ambiente de banco de dados relacional, bastaria realizar uma operação lógica: • Saiam todos que possuam média menor do que 5. Rudson Kiyoshi Souza Carvalho Página 37 Administração e Projeto de Banco de Dados Tabela Relacional Apresentamos abaixo uma relação de conceitos que definem uma tabela relacional: • Cada tabela é chamada de relação. • Uma linha e suas colunas chamam-se tupla. • Cada coluna dessa tabela tem um nome e representa um atributo da tabela. • A ordem das linhas é irrelevante. • Não há duas linhas iguais. • A ordem das colunas também é irrelevante. • Cada tabela tem nome próprio, distinto de qualquer outra tabela no banco de dados. Exemplo: Tabela de Funcionários: Nome Sexo Matrícula Departamento Cargo João Carlos M 373 TI-Operações Operador Carlos Brito M 872 TI-Programação Programador I Silvia Moraes F 963 TI-Análise Analista Sist. II Cláudia Tereza F 161 TI-Gerência Secretária Pedro Júlio M 292 RH Diretor Pedro Júlio M 574 TI-Análise Analista Sist. I Vamos analisar os dados: As matrículas não indicam a ordem das linhas, apresentando o conceito de que a ordem das linhas é irrelevante. Todas as colunas possuem um nome que significam algo. A ordem das colunasnão está desenvolvida para nenhuma finalidade de classificação ou ordem de leitura dos dados. Nenhuma linha se repete. Podemos ter duas pessoas com o mesmo nome, porém com matrículas diferentes. Rudson Kiyoshi Souza Carvalho Página 38 Administração e Projeto de Banco de Dados O conceito de Chave no Modelo Relacional Chave Primária (Primary Key) Em uma tabela existe uma coluna ou conjunto de colunas concatenados, cujo valor é único na tabela, ou seja, nunca se repete aquele valor em nenhuma outra linha da tabela, e que identifica uma e somente uma única linha da tabela. Então dizemos que esta coluna ou conjunto de colunas forma a chave primária da tabela. Na nossa tabela de funcionário, qual coluna ou conjunto de colunas concatenadas forma um identificador único para cada linha da tabela? Nome Sexo Matrícula Departamento Cargo João Carlos M 373 TI-Operações Operador Carlos Brito M 872 TI-Programação Programador I Silvia Moraes F 963 TI-Análise Analista Sist. II Cláudia Tereza F 161 TI-Gerência Secretária Pedro Júlio M 292 RH Diretor Pedro Júlio M 574 TI-Análise Analista Sist. I Nome? Com certeza não, pois se repete. Sexo? Também se repete. Departamento também não e cargo e salário sozinhos também não nos dizem nada. Sobra neste caso a única coluna que não tem valores repetidos, que é a matrícula. Existe somente um valor de matrícula para cada linha, o qual não se repete, logo podemos determinar que a Matrícula é a chave primária da tabela de Funcionários. Vamos agora observar uma tabela mais complicada, em que tenhamos que realizar um estudo maior para determinar a chave primária. Rudson Kiyoshi Souza Carvalho Página 39 Administração e Projeto de Banco de Dados Tabela de Consumos Bebida Qtde Valor Unit. Local Consumo Quarto Data Hora Valor Cerveja 2 3,00 Restaurante 101 22/01/2001 14:30 6,00 Chopp 3 2,00 Bar 203 19/01/2001 11:00 8,00 Cerveja 2 3,00 Restaurante 101 23/01/2001 14:30 6,00 Refrigerante 3 2,00 Restaurante 203 20/01/2001 08:45 6,00 Mate 1 1,50 Frigobar 407 21/01/2001 16:30 1,50 Café 1 0,80 Restaurante 203 18/01/2001 08:00 0,80 Suco 1 3,00 Service Room 505 22/01/2001 21:30 3,00 Mate 1 1,50 Restaurante 407 21/01/2001 16:30 1,50 Chopp 4 2,00 Bar 203 19/01/2001 17:10 8,00 Água 1 1,00 Frigobar 101 18/01/2001 08:30 1,00 Café 1 0,80 Restaurante 203 18/01/2001 18:00 0,80 Qual coluna ou conjunto de colunas poderíamos definir como identificador único de cada linha da tabela ? Poderia ser bebida? Não. Quarto, também não. Notem que nenhuma coluna sozinha poderia ser um identificador único da tabela. E se utilizarmos bebida e quarto? Note que a bebida cerveja foi consumida pelo quarto 101 mais de uma vez: Bebida Qtde Valor Unit. Local Consumo Quarto Data Hora Valor Cerveja 2 3,00 Restaurante 101 22/01/200 1 14:30 6,00 Cerveja 2 3,00 Restaurante 101 23/01/200 1 14:30 6,00 Se acrescentarmos o local de consumo à concatenação das colunas referidas, ainda não teríamos um identificador único. Bebida Qtde Valor Unit. Local Consumo Quarto Data Hora Valor Cerveja 2 3,00 Restaurante 101 22/01/200 1 14:30 6,00 Cerveja 2 3,00 Restaurante 101 23/01/200 1 14:30 6,00 Como os consumos foram realizados em datas diferentes, podemos inserir a data na composição da chave primária. Bebida Qtde Valor Unit. Local Consumo Quarto Data Hora Valor Cerveja 2 3,00 Restaurante 101 22/01/200 1 14:30 6,00 Cerveja 2 3,00 Restaurante 101 23/01/200 1 14:30 6,00 Desta vez os valores não se repetiriam. Porém, observe o consumo de mate pelo quarto 407. Rudson Kiyoshi Souza Carvalho Página 40 Administração e Projeto de Banco de Dados Bebida Qtde Valor Unit. Local Consumo Quarto Data Consumo Hora Consumo Valor Total Mate 1 1,50 Frigobar 407 21/01/200 1 16:30 1,50 Mate 1 1,50 Restaurante 407 21/01/200 1 16:30 1,50 Eles foram consumidos na mesma data, mas como o local de consumo é diferente, isso garante a integridade de nossa chave primária. Porém, o mesmo não ocorre com as duas linhas a seguir: Bebida Qtde Valor Unit. Local Consumo Quarto Data Consumo Hora Consumo Valor Total Café 1 0,80 Restaurante 203 18/01/200 1 08:00 0,80 Café 1 0,80 Restaurante 203 18/01/200 1 18:00 0,80 Aconteceram dois consumos de café pelo mesmo quarto (hóspede), no mesmo local e na mesma data. Isso nos diz que a chave primária definida até agora não está correta, pois existem linhas duplicadas para ela. Voltando a analisar as duas linhas acima, verificamos que o consumo foi realizado em horas diferentes. Dessa forma, se acrescentarmos a coluna “hora consumo” em nossa chave primária, passaríamos a ter duas linhas distintas. Bebida Qtde Valor Unit. Local Consumo Quarto Data Consumo Hora Consumo Valor Total Café 1 0,80 Restaurante 203 18/01/200 1 08:00 0,80 Café 1 0,80 Restaurante 203 18/01/200 1 18:00 0,80 Essa então é a nossa chave primária: • Bebida • Local de consumo • Quarto • Data consumo • Hora consumo Dessa forma, não poderíamos ter a mesma bebida, consumida pelo mesmo quarto (hospedagem), no mesmo local, na mesma data e na mesma hora, pois se isso ocorrer, deveremos alterar a quantidade consumida ao invés de inserirmos duas linhas na tabela. Chave Estrangeira (Foreign Key) Quando dizemos que duas tabelas estão relacionadas através de atributos (colunas) comuns, devemos observar que esta coluna é a chave primária em uma das tabelas. Na outra tabela, este atributo irá caracterizar o que chamamos de chave estrangeira, propiciando assim, uma ligação lógica (relacionamento) entre as tabelas. Exemplo: Rudson Kiyoshi Souza Carvalho Página 41 Administração e Projeto de Banco de Dados Chave Candidata Uma tabela relacional pode assumir alternativas de identificador único, ou seja, vária colunas ou concatenações delas podem ter essa propriedade. Estes identificadores são candidatos à chave primária. Como somente um poderá ser o escolhido (uma tabela só pode ter uma chave primária – que pode ser composta pela concatenação de mais de uma coluna), o restante passa a ser considerado como chave alternativa (secundária). Chave Secundária (Secundary Key) Serve para definir uma “segunda chave primária” através da criação de índices únicos de pesquisa. As chaves secundárias mantêm a integridade das tabelas que possuem mais de uma chave candidata. 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 valor zero nem o caractere branco, é simplesmente a não existência de conteúdo nesse campo. Integridade Referencial Se uma determinada tabela A possui uma chave estrangeira, a qual é chave primária em outra tabela B, então ela deve ser: • Igual a um valor de chave primária existente em B. • Nula (null). Não pode existir na chave estrangeira, um valor que não exista na tabela na qual ela é chave primária. As regras de integridade do modelo relacional representam a garantia de que as tabelas guardam informações compatíveis. São de extrema importância para a confiabilidade das informações contidas no banco de dados. Rudson Kiyoshi Souza Carvalho Página 42 Cód_Depto Departamento 1 TI-Análise 2 TI-Programação 3 TI-Operações 4 RH 5 TI-Gerência Nome Sexo Matrícula Depto João Carlos M 373 3 Carlos Brito M 872 2 Silvia Moraes F 963 1 Cláudia Tereza F 161 5 Pedro Júlio M 292 4 Pedro Júlio M 574 1 Departamento FuncionárioPossui Chave primária Chave estrangeira Administração e Projeto de Banco de Dados Características do Modelo Relacional • Uma tabela é acessível por qualquer campo (atributo) independente se este é declarado como chave ou não. • O relacionamento entre as tabelas não existe fisicamente, pois este relacionamento é apenas lógico e representado através das chaves estrangeiras. • Utilização de linguagens não procedurais (SQL). • Os ambientes
Compartilhar