Sabendo o suficiente sobre Bancos de Dados Relacionais
Construir um sistema no Oracle ou algum outro produto de banco de dados relacional não automaticamente torná-lo um banco de dados relacional. Da mesma forma, você pode criar um perfeitamente bom banco de dados relacional e implementá-lo em algo que não seja um produto de banco de dados relacional. Discutimos duas áreas importantes:
- O que as pessoas querem dizer com banco de dados relacional?
- Qual é o produto de banco de dados relacional do Oracle?
O que faz um banco de dados "relacional"?
Quando uma base de dados como está descrito relacional, ele foi concebido para estar em conformidade (pelo menos a maioria) com um conjunto das práticas de chamada regras de normalização. Um banco de dados normalizado é aquele que segue as regras de normalização.
Por exemplo, em uma organização, você tem funcionários que trabalham em departamentos específicos. Cada funcionário e departamento tem um número e um nome. Você poderia organizar esta informação como mostra a Tabela 1.
Tabela 1: Exemplo de Informações do Funcionário
| EmpNo | Ename | DEPTNO | NOMEDEPTO |
| 101 | Abigail | 10 | Marketing |
| 102 | Prumo | 20 | aquisitivo |
| 103 | Carolina | 10 | Marketing |
| 104 | Doug | 20 | aquisitivo |
| 105 | Evelyn | 10 | Marketing |
Se você estruturar seus dados desta forma e fazer algumas alterações nele, você terá problemas. Por exemplo, a exclusão de todos os funcionários no departamento de compras irá eliminar o departamento de si. Se você alterar o nome do departamento de Marketing "Publicidade", você precisa alterar o registro de cada funcionário do departamento.
Usando os princípios de bancos de dados relacionais, os dados do empregado e do departamento pode ser reestruturado em duas mesas separadas (DEPT e EMP), como mostrado nas Tabelas 2 e 3.
Tabela 2: uma tabela relacional DEPT Amostra
| DEPTNO | NOMEDEPTO |
| 10 | Marketing |
| 20 | aquisitivo |
Tabela 3: Uma Amostra relacional tabela EMP
| EmpNo | ENAME | DEPTNO |
| 101 | Abigail | 10 |
| 102 | Prumo | 20 |
| 103 | Carolina | 10 |
| 104 | Doug | 20 |
| 105 | Evelyn | 10 |
Usando essa estrutura, você pode examinar a tabela EMP para descobrir que Doug trabalha no departamento 20. Então você pode verificar a tabela DEPT para descobrir o que o departamento 20 está comprando. Você pode pensar que Tabela 1 parece mais eficiente. No entanto, a recuperação de informação que você precisa em uma série de maneiras diferentes é muito mais fácil com a estrutura de dois mesa. Juntando as informações nas duas tabelas para uma recuperação mais eficiente é exatamente o problema que bancos de dados relacionais foram projetados para resolver.
Quando as tabelas são implementadas no banco de dados, as informações nas duas tabelas está ligada por meio de colunas especiais chamados chaves estrangeiras. No exemplo, a coluna NUM_DEP é a chave estrangeira que liga as tabelas Departamento e Empregado.
As Tabelas 4 e 5 mostram uma outra estrutura de banco de dados comum, ou seja, uma ordem de compra (tabela PURCH_ORDER) para um item e os detalhes de informação associados a ordem de compra (tabela PURCH_ORDER_DTL) a.
Tabela 4: Uma Amostra Relational Tabela PURCH_ORDER
| PO_Nbr | Encontro |
| 450 | 12/10/2006 |
| 451 | 2006/02/26 |
| 452 | 2006/03/17 |
| 453 | 2006/06/05 |
Tabela 5: Uma Amostra Relational Tabela PURCH_ORDER_DTL
| PO_Nbr | Line_Nbr | Item | Qtde | Preço |
| 450 | 1 | Martelo | 1 | $ 10,00 |
| 451 | 1 | Chave de fenda | 1 | $ 8,00 |
| 451 | 2 | alicate | 2 | $ 6,50 |
| 451 | 3 | chave | 1 | $ 7,00 |
| 452 | 1 | chave | 3 | $ 7,00 |
| 452 | 2 | Martelo | 1 | $ 10,00 |
| 453 | 1 | alicate | 1 | $ 6,50 |
A ordem de compra pode incluir muitos itens. Tabela 5 mostra que Purchase Order 451 inclui três itens separados. O link (chave estrangeira) entre as mesas é o Pedido de Compra Number.
terminologia de banco de dados básico entendimento
Um banco de dados consiste em tabelas e colunas, conforme descrito na secção anterior. Há alguns outros termos que você precisa saber para entender como bancos de dados funciona. Um banco de dados é construído em duas fases. Primeiro você cria um modelo lógico de dados colocar para fora o design do banco de dados e como serão organizados os dados. Então você implementar o banco de dados de acordo com o modelo de dados físico, que estabelece as tabelas e colunas reais. Uma terminologia diferente se aplica aos elementos dos desenhos lógicos e físicos. Além disso, os designers de banco de dados relacionais usam palavras diferentes de designers (OO) de banco de dados orientado a objetos para descrever os elementos do banco de dados. A Tabela 6 mostra as palavras usadas em cada um destes casos.
Tabela 6: Banco de dados Projeto de Terminologia
| Lógico / Relacional | Lógico / Orientada a Objetos | A implementação física |
| Entidade | Classe | Mesa |
| Atributo | Atributo | Coluna |
| Instância | Objeto | Linha |
As definições dos termos na Tabela 6 são os seguintes:
- Entidade: Uma entidade corresponde a algo no mundo real que é de interesse e que você deseja armazenar informações sobre. Exemplos de entidades incluem coisas tais como departamentos dentro de uma organização, funcionários ou vendas. Cada departamento ou funcionário específico é considerado um instância dessa entidade. Por exemplo, na Tabela 3, Doug é uma instância do empregado entidade. (No mundo OO, Doug seria um objeto na classe Employee.)
- Atributo: Esta palavra é usada em ambos os bancos de dados relacionais e OO para representar informações sobre uma instância de entidade ou um objeto que serão rastreados. Um exemplo de um atributo pode ser a data de nascimento ou número de segurança social de um funcionário.
- Entidades (classes), seus atributos e instâncias (objetos): Eles são implementados no banco de dados como tabelas, colunas e linhas respectivamente.
Um conceito adicional importante para entender quando se lida com bancos de dados relacionais é a chave primária. UMA chave primária identifica exclusivamente uma instância específica de uma entidade. Não há duas instâncias de uma entidade pode ter a mesma chave primária. Os valores de todas as partes da chave primária não deve ser nulo. Os tipos mais comuns de chaves primárias em bancos de dados relacionais são números de identificação. Por exemplo, na Tabela 3, a EmpID pode ser a chave primária. Às vezes, mais do que um atributo (ou conjuntos de atributos) pode ser usado como uma chave primária. Estes atributos são chamados chaves candidatas, um conjunto de qual deve ser designado como a chave primária.