Como projetar um banco de dados SQL

O primeiro passo para projetar qualquer banco de dados SQL é identificar o que incluir eo que não incluir. Os próximos passos envolvem decidir como os itens incluídos se relacionam entre si e, em seguida, a criação de tabelas em conformidade.

Para criar um banco de dados em SQL, siga estas etapas básicas:

1. Decida o que os objetos que você deseja incluir em seu banco de dados.

2. Determinar quais desses objetos devem ser tabelas e que deve ser colunas dentro dessas tabelas.

3. Definir tabelas com base em como você precisa para organizar os objetos.

   Opcionalmente, você pode querer designar uma coluna de tabela ou uma combinação de colunas como uma chave.

Passo 1: Definir objetos

O primeiro passo na criação de um banco de dados é decidir quais os aspectos do sistema são importantes o suficiente para incluir no modelo. Trate cada aspecto como um objeto e criar uma lista de todos os objetos que você pode pensar. Nesta fase, não tentar decidir como esses objetos se relacionam entre si. Basta tentar enumerá-los todos.

Quando você tem um conjunto razoavelmente completo de objetos, passar para o próximo passo: decidir como esses objetos se relacionam entre si. Alguns dos objetos são as principais entidades que são cruciais para dar-lhe os resultados desejados. Outros objetos são subsidiária às grandes entidades. Em última análise, você pode decidir que alguns objetos não pertencem ao modelo em tudo.

Passo 2: Identificar tabelas e colunas

entidades principais traduzir-se em tabelas de banco de dados. Cada entidade principal tem um conjunto de atributos - as colunas da tabela. Muitos bancos de dados de negócios, por exemplo, tem uma tabela de clientes que mantém o controle de nomes, endereços e outras informações permanente dos clientes. Cada atributo de um cliente - tais como nome, rua, cidade, estado, CEP, número de telefone e endereço de e-mail - torna-se uma coluna (e um título de coluna) na tabela de clientes.

Se você está esperando para encontrar um conjunto de regras para ajudar a identificar quais objetos devem ser tabelas e quais os atributos do sistema pertencem a qual mesas, pense novamente: Você pode ter algumas razões para a atribuição de um determinado atributo a uma mesa e outras razões para atribuir o mesmo atributo para outra mesa. Você deve basear seu julgamento em duas metas:

• A informação que você deseja obter a partir do banco de dados

• Como você pretende usar essa informação

Ao decidir como estruturar tabelas de banco de dados, envolver os futuros usuários do banco de dados, bem como as pessoas que tomam decisões com base em informações do banco de dados. Se você vir para cima com o que você acha que é uma estrutura razoável, mas não é consistente com a maneira que as pessoas vão usar as informações, o sistema vai ser frustrante para usar na melhor das hipóteses - e poderia até mesmo produzir informação errada, o que é ainda pior .

Dê uma olhada em um exemplo. Suponha que você VetLab apenas estabelecido, um laboratório de microbiologia clínica que testa amostras biológicas enviadas pelos veterinários. Você deseja controlar várias coisas, incluindo o seguinte:

• clientes

• Testes que você executa

• funcionários

• encomendas

• Resultados

Passo 3: Definir tabelas

Agora você deseja definir uma tabela para cada entidade e uma coluna para cada atributo.

Mesa	colunas
CLIENTE	Nome do cliente
Endereço 1
Endereço 2
Cidade
Estado
Código postal
Telefone
Fax
Pessoa de contato
TESTES	Nome de teste
Custo padrão
EMPREGADO	nome do empregado
Endereço 1
Endereço 2
Cidade
Estado
Código postal
Telefone residencial
Extensão de escritório
Data de contratação
classificação profissional
Por hora / salário / Comissão
ORDENS	Número do pedido
Nome do cliente
teste ordenado
Vendedor responsável
Data do pedido
RESULTADOS	número-resultado
Número do pedido
Resultado
data do Alerta
Preliminar / Final

Você pode criar as tabelas definidas aqui, usando tanto um desenvolvimento rápido de aplicações da ferramenta (RAD) ou usando o SQL Data Definition Language (DDL), como mostrado no seguinte código:

CRIAR CLIENTE TABLE (NomeCliente CHAR (30) NOT NULL, Address1 CHAR (30), Endereço2 CHAR (30), CityCHAR (25), StateCHAR (2), PostalCode CHAR (10), PhoneCHAR (13), FaxCHAR (13), Contactperson CHAR (30)) Testes -Criar mesa (TestName CHAR (30) NOT NULL, StandardCharge CHAR (30)) -Criar tabela de funcionários (EmployeeName CHAR (30) NOT NULL, Address1 CHAR (30), Endereço2 CHAR (30), CityCHAR (25), StateCHAR (2), PostalCode CHAR (10), HomePhone CHAR (13), OfficeExtension CHAR (4), HireDate DATA, JobClassification CHAR (10), HourSalComm CHAR (1)) tabela pedidos -Criar (OrderNumber INTEIRO NOT NULL, NomeCliente CHAR (30), TestOrdered CHAR (30), Vendedor de CHAR (30), OrderDate DATE) RESULTADOS A Tabela -Criar (ResultNumber INTEGER NOT NULL, OrderNumber INTEIRO, Resultado CHAR (50), DateReported DATA, PrelimFinal CHAR (1 )) -

Estas tabelas relacionam entre si pelos atributos (colunas) que partilham, como a lista que se segue descreve:

• Os links da tabela cliente para a tabela PEDIDOS pelo Nome do cliente coluna.

• Os links da tabela testes para a tabela PEDIDOS pelo TestName (TestOrdered) coluna.

• Os links tabela de funcionários para a tabela de pedidos até o EmployeeName (vendedor) coluna.

• Os links tabela de resultados para a tabela de pedidos até o Número do pedido coluna.

Se você quer uma mesa para servir como parte integrante de um banco de dados relacional, vincular essa tabela para pelo menos uma outra tabela no banco de dados, utilizando uma coluna comum.

Os links ilustram quatro diferentes um para muitos relacionamentos. O diamante no meio de cada relação mostra a cardinalidade máxima de cada extremidade da relação. O número 1 indica a # 147-one # 148- lado do relacionamento, e N denota o # 147-muitos # 148- lado.

• Um cliente pode fazer muitas ordens, mas cada pedido é feito por um, e apenas um, cliente.

• Cada teste pode aparecer em muitas ordens, mas cada ordem apela a um, e apenas um, teste.

• Cada ordem é tomado por um, e apenas um, empregado (ou vendedor), mas cada vendedor pode tomar várias ordens.

• Cada pedido pode produzir vários resultados de testes preliminares e um resultado final, mas cada resultado está associado com um, e apenas um, ordem.

O atributo que liga uma tabela para outra pode ter um nome diferente em cada mesa. Ambos os atributos devem, no entanto, têm tipos de dados correspondentes.