Ementrio Viso geral do gerenciamento de banco de
Ementário • • Visão geral do gerenciamento de banco de dados. Modelo Entidade-Relacionamento (E-R) Modelo Relacional Álgebra relacional SQL Outras Linguagens Relacionais Regras de Integridade Especificar os dados de um Sistema de Informação utilizando as formas normais. Definir o modelo conceitual dos dados normalizados.
Revisão (1/3) Acima da estrutura do banco de dados está o modelo de dados: um conjunto de ferramentas conceituais usadas para a descrição de dados, relacionamentos entre os dados, semânticas de dados e regras de consistências. Modelo de Dados = descrição formal da estrutura de um banco de dados. Ou ainda, descrição das informações que estão armazenadas em um banco de dados.
Revisão (2/3) Os vários modelos que vêm sendo desenvolvidos são classificados em três diferentes grupos: (1) modelos lógicos com base em objetos (modelo conceitual): – modelo entidade-relacionamento (E-R), modelo orientado a objetos, modelo semântico de dados e modelo funcional de dados. (2) modelos lógicos com base em registros (modelo lógico): – modelo relacional, modelo de rede e modelo hieráquico. (3) modelos físicos (descrevem os dados em seu nível mais baixo).
Revisão (3/3) É parte integral do processo de desenvolvimento de um sistema de informação e pode ser definido como uma atividade que organiza as informações e os requisitos de processamento de uma aplicação em uma representação definida por meio de estruturas, restrições de integridade e operações. Projeto de Banco de Dados: Projeto Conceitual, Projeto Lógico e Projeto Físico.
Projeto de Banco de Dados Projeto Conceitual: trata da modelagem conceitual do banco de dados independente do modelo do SGBD. Produção de uma descrição formal dos dados e processos a partir da definição dos requisitos do usuário. Projeto Lógico: traduz os modelos conceituais no modelo de dados (esquema) de um SGBD. Projeto Físico: estruturas físicas de armazenamento e métodos de acesso que irão suportar eficientemente as estruturas lógicas definidas nas fases anteriores.
Esquema Geral do Projeto de Banco de Dados Problema Análise de Requisitos (requisitos da base de dados) Arquitetura Geral Projeto Detalhado Projeto Conceitual (Diagrama Entidade-Relacionamento) esquema conceitual em um modelo de dados de alto-nível independente de qualquer SGBD específico Projeto do Programa de Aplicação (ambiente de desenvolvimento: Java, Delphi, …) Implementação da Transação (stored procedures) Projeto Lógico Mapeamento do Modelo de Dados: esquema conceitual em um modelo de dados de um SGBD específico Projeto Físico esquema interno
História • Os princípios do modelo relacional foram introduzidos por E. F. Codd em 1970, na época pesquisador da IBM. Essas ideias foram disseminadas no artigo: A Relational Model of Data for Large Shared Data Banks. (http: //www. cs. nott. ac. uk/~nza/G 51 DBS/codd. pdf ) • Meados da década de 70: protótipos – INGRES (UC Berkeley, 73 – 77) – System R (IBM Research at San Jose, 74 – 78) • 1979: primeiro produto SQL (Oracle) • Meados da década de 80: predominância relacional absoluta no mercado de SGBDs. • Recentemente: IBM, Oracle, Sybase, Informix, Microsoft (robustos para aplicações convencionais).
O Modelo de Dados Relacional (1/2) Corresponde ao conceito matemático de: Relação: é um subconjunto do produto cartesiano de uma lista de domínios. • domínio: conjunto de valores permitidos ao atributo • produto cartesiano: dados os domínios D 1 e D 2, o produto cartesiano (ou produto direto) é o conjunto de todos os pares ordenados com o primeiro elemento de cada par (ou tupla) pertencente a D 1 e o segundo, a D 2. D 1 D 2 = { (x, y) | x pertence a D 1 e y pertence a D 2 } D 1 = { 0, 1 } D 2 = { a, b, c } D 1 D 2 = { (0, a), (0, b), (0, c), (1, a), (1, b), (1, c) } Tupla: é um membro da relação. Aridade ou Nível: uma relação que é um subconjunto do produto cartesiano de k domínios é dito como tendo aridade k.
(Relação X Tupla) (Tabela X Registro) Dados os domínios Nomes e Salários: Nomes = { joão, maria, ana } Salários = { R$ 1000. 00, R$ 2000. 00 } Produto Cartesiano dos domínos Nomes e Salários: Nomes Salários = { (joão, R$ 1000. 00), (joão, R$ 2000. 00), (maria, R$ 1000. 00), (maria, R$ 2000. 00), (ana, R$ 1000. 00), (ana, R$ 2000. 00) } Relação: é um subconjunto do produto cartesiano Tabela { (joão, R$ 1000. 00), (maria, R$ 2000. 00), (ana, R$ 1000. 00) } Tupla: é um membro da relação (maria, R$ 2000. 00) Registro
O Modelo de Dados Relacional (2/2) Relação Visto como Tabela Composto de Linha: Tupla (registro) Coluna: Atributo ou Componente (campo) Relação ou Tabela Colunas: Atributos ou Componentes (campos) Linhas: Tuplas (registros)
Conceitos Básicos (1/2) • Noção fundamental: a “relação” e a formalização matemática da ideia informal de “tabela”. • Banco de Dados relacional: conjunto de relações (ou tabelas). • Relação: conjunto de tuplas (linhas, ou registros da tabela). • Cada tupla é uma lista de valores de atributos (campos ou colunas da tabela).
Banco de dados relacional: conjunto de relações (tabelas). Linhas: Tuplas (registros) Colunas: Atributos ou Componentes (campos)
Conceitos Básicos (2/2) • Esquema de uma relação: especifica o nome da relação (tabela), mais o nome e o tipo de cada atributo (campo, ou coluna). – Professores(CDPROF: integer, NOMEPROF: string, CDTITULO: integer, DTNSCTO: date, EMAIL: string, CDCURSO: integer) – Grau: número de colunas da relação. • Instância de uma relação: conteúdo da tabela, sendo que a Cardinalidade é o número de tuplas (linhas) da relação. • Esquema do banco de dados: conjunto de esquemas das relações mantidas no BD. Projeto Geral do BD. • Instância do banco de dados: conjunto das instâncias das relações mantidas no BD. Conjunto de Informações.
Exemplo de Instância de Relação ou Tabela Colunas: Atributos ou Componentes (campos) Grau = 6 Linhas: Tuplas (registros) Cardinalidade = 12
Esquema E-R na Forma Tabular Um banco de dados em conformidade com o esquema de banco de dados E-R pode ser representado por uma coleção de relações. Para cada conjunto de entidades (tuplas) e para cada conjunto de relacionamentos (tuplas), dentro de um banco de dados, existe uma tabela única. Cada tabela possui várias colunas (campos), uma para cada atributo da entidade, e cada uma delas com um único nome. Tanto o “modelo E-R” quanto o “modelo relacional” são abstratos, ou seja, representações lógicas de empresas reais. Como esses dois modelos empregam princípios de projetos similares, podemos converter o projeto E-R em projeto relacional. Converter a representação de um banco de dados de um diagrama E-R de um projeto a partir de um banco de dados relacional.
Conjuntos de Entidades Primeiro. Nomes. Do. Meio CPF Nome Último. Nome Salário Funcionários CPF Primeiro. Nomes. Do. Meio Último. Nome Salário • Para cada conjunto de entidades criar uma relação (tabela). • Para cada atributo simples (CPF, Salário) incluir uma coluna na tabela. • No caso de atributo composto (Nome), incluir somente os atributos simples que o compõe (Primeiro. Nome, Nomes. Do. Meio e Último. Nome).
Atributos Multivalorados Primeiro. Nomes. Do. Meio CPF Nome Último. Nome Salário Funcionários Telefones CPF Primeiro. Nomes. Do. Meio Último. Nome Salário CPF Telefone • Para cada atributo multivalorado criar uma tabela contendo: • Como chave estrangeira, a chave primária (CPF) da tabela que representa o conjunto de entidades que tem o atributo multivalorado. • O valor do atributo. • A chave primária da nova tabela é a combinação da chave estrangeira e do valor do atributo.
Revendo conceitos de Chaves A noção de superchave, chave candidata e chave primária discutidas no modelo E-R também podem ser aplicadas ao modelo relacional. • Superchave: um conjunto de uma ou mais colunas que, tomadas coletivamente, permitem identificar de maneira unívoca uma tupla em uma relação. • Chaves candidatas: todas as colunas que podem servir como superchave. • Chave primária: chave candidata escolhida pelo projetista do banco de dados como de significado principal para a identificação de tuplas dentro de uma relação.
Classificação de Chaves Primárias Simples: formada por apenas um atributo Funcionários (CPF, nome, salário) Composta: formada por mais de um atributo Participações (CPFParticipante, Num. P, Hora. Por. Semana) Chave Estrangeira: é um atributo ou conjunto de atributos cujos valores aparecem necessariamente na chave primária de uma tabela. Este mecanismo permite a implementação de relacionamentos no modelo relacional. Departamentos (num. D, nome. D, ramal) Funcionários (CPF, nome, salário, num. D, data. Lotação)
Restrições Chave Estrangeira (FK) Inclusão de um registro na tabela que contém a FK: Deve ser garantido que o valor da chave estrangeira apareça na coluna da chave primária (PK) referenciada. Alteração do valor da chave estrangeira: Deve ser garantido que o novo valor da chave estrangeira apareça na coluna da chave primária referenciada. Exclusão de um registro da tabela que contém a PK referenciada pela FK (deixar registros órfãos): Deve ser garantido que na coluna chave estrangeira não apareça o valor da chave primária que está sendo excluída. Alteração do valor da PK referenciada pela FK: Deve ser garantido que na coluna chave estrangeira não apareça o antigo valor da chave primária que está sendo alterada.
Conceitos do modelo E-R: Entidade Fraca X Entidade Forte • Entidades Fracas: são aquelas que “não” possuem atributos suficientes para formar uma chave primária. • Entidades Fortes: são aquelas que “possuem” atributos para formar uma chave primária. Identificador, ou discriminador: é o conjunto de atributos da entidade que tem a propriedade de determinar de forma única cada instância da entidade.
Chave Entidades Fortes X Entidades Fracas • Conjunto de entidades fortes: “parte” da chave primária (CPFdo. Responsável) do conjunto de relacionamento é a chave primária da relação Funcionários (CPF). • Conjunto de entidades fracas: a relação Dependentes é formada pelos atributos da entidade fraca (Nro. Seq, Nome. Dep e Dt. Nscto) e a chave primária do conjunto de entidades fortes (CPFdo. Responsável). Chave composta (CPFdo. Responsável + Nro. Seq). Entidade Forte Entidade Fraca Nome Nro. Seq Nome. Dep Salário CPF Funcionários (0, n) Dt. Nscto Dependências (1, 1) Dependentes Funcionários Dependentes (conjunto de relacionamento) CPF Nome Salário CPFdo. Responsável Nro. Seq Nome. Dep Dt. Nasc O atributo Nro. Seq é uma chave parcial, que distingue os vários dependentes de um dado funcionário. Para se determinar um dependente precisa-se também do CPF do funcionário.
Chave Conjuntos de Relacionamentos (Binários) Um para Um (1/2) • Com duas tabelas, uma para cada conjunto de entidades que participa do relacionamento. • Na entidade que participa do relacionamento de forma total deve-se incluir como chave estrangeira (CPFdo. Gerente) a chave primária da entidade que participa parcialmente do relacionamento. • Incluir também colunas com os atributos do relacionamento. CPF Nome Funcionários Salário Num. D (0, 1) 1 (1, 1) Gerências 1 Nome. D Descr. D Departamentos Data. Início Funcionários Departamentos CPF Nome Salário Num. D Nome. D Descr. D CPFdo. Gerente Data. Inicio
Chave Conjuntos de Relacionamentos (Binários) Um para Um (2/2) Para manter o histórico indicando “todos” os funcionários que foram gerentes de um departamento ao longo da história. Usa-se o atributo descritivo que indica o “Data. Início” da gerência como multivalorado. CPF Nome Funcionários Num. D Salário (0, 1) 1 Gerências (1, 1) 1 Nome. D Descr. D Departamentos Data. Início Funcionários Gerências Departamentos CPF Nome Salário Num. D CPFdo. Gerente Data. Início Num. D Nome. D Descr. D
Chave Conjuntos de Relacionamentos (Binários) Muitos para Um (1/3) • Tabelas combinadas. Com duas tabelas, uma para cada conjunto de entidades que participa do relacionamento. • Incluir como chave estrangeira, na tabela do “lado muitos” (ou “lado N”), a chave primária (Num. D) da tabela do “lado um”. • Incluir também colunas com os atributos do relacionamento. CPF Nome Funcionários Num. D Salário (1, 1) N Lotações (4, n) 1 Nome. D Descr. D Departamentos Data. Lotação Funcionários Departamentos CPF Nome Salário Num. D Data. Lotação Num. D Nome. D Descr. D
Chave Conjuntos de Relacionamentos (Binários) Muitos para Um (2/3) Para manter o histórico indicando “todos” os departamentos pelos quais um funcionário esteve matriculado (ou lotado) ao longo da história. Usa-se o atributo descritivo que indica a “Data. Lotação” da gerência como multivalorado. CPF Nome Funcionários Num. D Salário (1, 1) N Lotações (4, n) 1 Nome. D Descr. D Departamentos Data. Lotação Funcionários Lotações Departamentos CPF Nome Salário CPF Num. D Data. Lotação Num. D Nome. D Descr. D
Chave Conjuntos de Relacionamentos (Binários) Muitos para Um (3/3) Neste caso, não é interessante incluir como chave estrangeira, na tabela do “lado muitos” (ou “lado N”), a chave primária da tabela do “lado um”. Uma vez que a entidade Médicos tem uma participação parcial no relacionamento, ou seja, o médico atende ou não em ambulatórios do hospital. Sendo assim, sugere-se a criação de uma tabela que represente o relacionamento de médicos que atendem em ambulatórios combinando as chaves estrangeiras para formar a chave primária na nova tabela. CRM Médicos número Especialidade Nome (0, 1) N Atendem (2, 20) 1 Andar Capacidade Ambulatórios Médicos Atendem Ambulatórios CRM Nome Especialidade número CRM número Andar Capacidade
Chave Conjuntos de Relacionamentos (Binários) Muitos para Muitos • Com duas tabelas, uma para cada conjunto de entidades que participa do relacionamento. Criar uma nova tabela contendo, como chaves estrangeiras, as chaves primárias dessas duas tabelas (CPFdo. Participante e Num. P). • A combinação dessas chaves estrangeiras forma a chave primária da nova tabela. • Incluir também colunas com os atributos do relacionamento. CPF Num. P Salário Nome Funcionários (0, n) M Participações (1, n) N Nome. P Descr. P Projetos Horas. Por. Semana Funcionários Participações (conjunto de relacionamentos) Projetos CPF Nome Salário CPFdo. Participante Num. P Horas. Por. Semana Num. P Nome. P Descr. P
Chave Conjuntos de Relacionamentos Ternário • Criar uma nova tabela (Vendas) com a chave primária “composta” das chaves primárias das tabelas que representam os conjuntos de entidades participantes. • se a cardinalidade máxima de uma das entidades participantes for 1, então criar uma chave estrangeira que referencia a chave primária da tabela participantes. • Incluir também colunas com os atributos do relacionamento. obs. avaliar a possibilidade de usar um atributo de autonumeração para identificar as vendas. (0, n) Vendedores Num. Vendedor . . . (0, n) Vendas Data Quantidade (0, n) Produtos Compradores Num. Comprador Num. Produto . . . Vendas (conjunto de relacionamentos) Num. Vendedor Num. Comprador Num. Produto Data Quantidade . . .
Generalização / Especialização CPF Nome Abordagem geral: “ 3 tabelas” Endereço Prestadores de Serviços CPF Nome Endereço Horistas CPF Custo. Por. Horas. Trabalhadas Generalização Tipo Especialização Mensalistas CPF Salário Horistas Custo. Por. Hora Mensalistas Horas. Trabalhadas Salário Alternativa: “ 2 tabelas” Horistas Mensalistas CPF Nome Endereço Custo. Por. Horas. Trabalhadas CPF Nome Endereço Salário
Em Síntese • Para “tabular” relacionamentos: – um relacionamento binário 1: 1, 1: N ou N: 1 é tabulado pela junção de duas tabelas através de “chave estrangeira”; – um relacionamento binário M: N é tabulado pela junção de três tabelas, combinando as chaves primárias na terceira tabela; – um relacionamento ternário é tabulado pela junção de quatro tabelas, combinando as chaves primárias na quarta tabela. • Para obter os valores de um atributo multivalorado: – precisa-se fazer a junção de duas tabelas. • Para trabalhar com generalização/especialização: – na abordagem geral (uma tabela para a superclasse, mais uma tabela para cada subclasse), para obter todos os dados de um subclasse precisa-se fazer a junção de duas tabelas. – na abordagem alternativa desfaz-se a herança.
Linguagens de Consulta (1/2) • Uma linguagem de consulta (query language) é a linguagem por meio da qual os usuários obtêm informações do banco de dados. • As linguagens de consulta podem ser categorizadas como procedurais ou não-procedurais. • Em uma linguagem procedural, o usuário deve “ensinar” ao sistema a realização de um “sequência de operações” no banco de dados para obter o resultado desejado. • Em uma linguagem não-procedural (ou declarativa), o usuário “descreve a informação” desejada “sem fornecer um procedimento” específico para a obtenção dessas informações.
Linguagens de Consulta (2/2) • Os sistemas de banco de dados comerciais oferecem uma linguagem de consulta que incorpora elementos de ambos os enfoques: procedurais e não-procedurais. • Exemplos de linguagens comerciais: SQL, Query -by-Example, Quel, Datalog. • Como exemplo de linguagem procedural “pura”: álgebra relacional. • Essas linguagens são concisas e formais, mas ilustram as técnicas fundamentais para a extração de dados do banco de dados.
Referências • Sistema de Banco de Dados. – Abraham Silberschatz; Henry F. Korth; S. Sudarshan. – Capítulo 3: Modelo relacional – São Paulo: Makron Books, 3ª ed. , 1999. • Prof. Francisco Reverbel – http: //www. ime. usp. br/~reverbel/
- Slides: 34