Trab bd ficticia

Mestrado em Análise de Dados e Sistemas de Apoio à Decisão

Faculdade de Economia

Universidade de Porto

Bases de Dados e Programação

TRABALHO DE BASES DE DADOS

Manuel José Ferreira Monteiro

Fevereiro de 2006

ÍNDICE

1. Introdução......................................................................................................................3

2. Ciclo de vida na criação de uma base de dados.............................................................5

3. Descrição do “Negócio” ................................................................................................6

4. Modelo entidade-relacionamento ................................................................................11

4.1 Descrição do modelo Entidade-Relacionamento.................................................. 11

4.2 Identificação das principais Entidades e Relações ............................................... 12

4.3 Construção do modelo ER.................................................................................... 13

5. Modelo relacional........................................................................................................20

6. Normalização...............................................................................................................29

7. Criação da Base de Dados em MYSQL ......................................................................30

8. Consultas SQL.............................................................................................................39

9. Conteúdos Consultados ...............................................................................................43

Bases de Dados e Programação MADSAD-FE-UP

3

1. Introdução

Este trabalho pretende abordar os conceitos estudados na disciplina de “Bases de Dados e Programação” na componente de Bases de Dados.

Para aplicação dos métodos e conhecimentos estudados utilizou-se um caso real onde a solução encontrada neste documento será efectivamente aplicada.

Utilizaram-se os seguintes sistemas e ferramentas:

MYSQL

O MYSQL é um sistema de gestão de bases de dados relacional baseado em comandos SQL (Structured Query Language), sendo actualmente um dos sistemas mais utilizados. Trata-se de um sistema OpenSource.

Foi utilizado neste trabalho como sistema de base de dados.

Informações e download em: http://www.mysql.com/

DBDesigner 4

O DBDesigner 4 é um sistema visual para desenho de bases de dados que integra desenho de bases de dados, modelação, criação e manutenção num único ambiente. Foi desenvolvido e optimizado para o MYSQL.

Foi utilizado neste trabalho para se criar o modelo ER.

Informações e download em: http://www.fabforce.net/dbdesigner4/


4

MYSQL Query

O MYSQL Query é uma ferramenta disponibilizada no site do MYSQL que permite de uma forma simples e visual criar e gerir bases de dados MYSQL.

Em complemento com o DBdesigner, foi utilizado neste trabalho para se criarem todas as tabelas e para se fazerem interrogações SQL.

Informações e download em: http://dev.mysql.com/downloads/query-browser/1.1.html

VISIO

O Microsoft Visio é uma ferramenta visual adequada para a elaboração de diagramas e outros esquemas baseados em objectos.

Foi utilizado neste trabalho para elaboração de todos os esquemas representativos do modelo ER.

Informações em: http://office.microsoft.com/en-us/FX010857981033.aspx


5

2. Ciclo de vida na criação de uma base de dados

Os passos necessários no desenvolvimento de uma base de dados podem resumidamente ser os seguintes:

Passo 1: Analisar o sistema (negócio)

Nesta fase avalia-se o modelo de negócio. O analista ouve os utilizadores sobre a forma como utilizam a informação. É um processo cíclico onde os utilizadores, conhecedores profundos do negócio, explicam ao analista, que poderá perceber pouco do modelo em causa, todos os pormenores sobre como os dados circulam e são armazenados na organização e a informação que desejam obter.

Passo 2: Especificar a base de dados

Havendo um conhecimento inicial das necessidades do negócio em termos de informação inicia-se a fase onde o analista descreve e esquematiza o modelo. Sendo o utilizador final pouco conhecedor das metodologias e modelos utilizados na construção de uma base de dados, pode-se complementar os modelos que serão construídos com descrições básicas sobre o que a base de dados deve conter e como as partes se interligam. Quando o analista descreve uma relação como, por exemplo “Todos os empregados emitem facturas”, o utilizador final pode facilmente confirmar essa regra, negar ou modificar a declaração para que se ajuste à realidade.

Passo 3: Desenhar a base de dados

Assim que o modelo está preparado pode-se passar à fase de construção da base de dados propriamente dita. Nesta fase surgem normalmente novas oportunidades de melhoria, tal como aconteceu com este trabalho. Convertendo os modelos obtidos para tabelas relacionais e iniciando os testes SQL à base de dados criada, surgirão sempre novas oportunidades de optimização da base de dados.


6

3. Descrição do “Negócio”

Apresentação

A FICTICIA é uma empresa com actuação Internacional que oferece serviços na área da Internet. O seu “Core Business” é fundamentalmente a venda de serviços de WebHosting e Registo de Domínios.

Praticamente todos os clientes são angariados na Internet, que em qualquer altura do dia (24 horas por dia e 7 dias por semana) podem realizar encomendas online ou solicitar qualquer tipo de apoio administrativo ou técnico.

Os produtos/serviços vendidos estão padronizados sendo a empresa passível de grande automatização.

A motivação

A empresa pretende reformular radicalmente o seu sistema de informação actual, dotando-o de ferramentas que lhe possibilite obter de uma forma mais rápida e automatizada a informação para gestão eficaz do negócio.

Trata-se de uma área de negócio muito dinâmica onde é exigida uma resposta muito rápida às solicitações dos clientes. Estes pretendem ser rapidamente servidos em qualquer uma das fases da relação fornecedor/cliente.

Principais problemas

Actualmente tem um sistema informático que utiliza uma base de dados extremamente simples que já não responde às necessidades de informação da empresa, num mercado que é extremamente competitivo.

A actual base de dados não está normalizada nem está dotada com dados úteis ao funcionamento da empresa.


7

Um esquema ER simplificado da actual Base de Dados:

O grande handicap da empresa é o elevado índice de incobráveis. Pretende-se com este novo sistema de informação, aliado a algumas técnicas de detecção de fraudes e integração de sistemas de pagamento online, minimizar consideravelmente as elevadas perdas financeiras por encomendas não pagas.

Pressupostos gerais sobre a empresa

P1. A empresa lida com encomendas online, podendo ser essas encomendas de serviços de alojamento e/ou registo de domínios.

P2. O processo desde que é realizada a encomenda até à entrega do serviço segue a seguinte lógica:

Cliente:Encomenda ---> Empresa:Validação dos dados ----> Empresa:Envio de nota de cobrança ---> Cliente:Pagamento ---> Empresa:Confirmação do pagamento ---> Empresa:Envio da factura (Normal ou Electrónica) ---> Empresa:Entrega do serviço

FACTURAS

CLIENTES PRODUTOS

PagaSão Pagas

UtilizaSão

utilizados

ContemContidos


8

P3. O estado do processo será monitorizado pela Empresa

P4. Os serviços podem ser mensais ou anuais e têm associado um preço, que pode variar no tempo.

P5. Os clientes podem ser de qualquer país pelo que poderão ter diferentes tratamentos em termos de tributação do IVA e lingua nas respostas. A estes está associada uma pessoa de contacto. Um cliente pode estar associado a muitos serviços.

P6. Às encomendas ficam associados alguns dados extraídos da Internet, nomeadamente o IP de origem da encomenda, o dia, hora e site de onde partiu a referência (motores de busca, caso exista), qual a palavra que deu origem à referência. Com estes dados pretende-se saber o retorno dos investimento publicitários, estatísticas sobre número de encomendas diárias, mensais e anuais. Pretende-se igualmente avaliar outros comportamentos associados ao processo da encomenda.

P7. A Empresa está associada a outras entidades que revendem os seus serviços e com os quais é negociada uma margem que pode variar de revendedor para revendedor. Um revendedor é por norma igualmente um cliente.

P8. Há clientes que têm igualmente um tratamento especial podendo ter preços diferentes dos praticados ao público.

P9. Os clientes devem ser avisados por SMS e email quando os domínios estão próximo de caducar para que possam proceder à sua renovação. O cliente poderá escolher com que antecedência pretende ser avisado. Poderá haver alguns clientes que preferem que a renovação do domínio seja automatizada.

P10. Os clientes podem pagar por Cartão de Crédito (Visa, Master Card e outros), Pagamento de Serviços (apenas em Portugal), Cheque, Transferência ou Depósito. Estas opções aparecem ao cliente no acto de encomenda. No caso de pagamento por cartão de crédito os dados associados ao cartão são armazenados temporariamente até que se proceda ao pagamento. Por questões de segurança esses dados serão encriptados e guardados em tabelas separadas.


9

P11. Os dados dos pagamentos realizados pelos clientes são guardados.

P12. O cliente pode optar por factura electrónica ou tradicional (por correio).

P13. Frequentemente os clientes fazem Upgrade (ou Downgrade) da conta de alojamento que possuem. Essas mudanças devem ser guardadas para futura referência.

P14. Os contactos de suporte técnico ou administrativo realizados entre o cliente e a 4Ever devem ficar guardados para futura referência.

P15. As ocorrências técnicas associadas a um domínio ou a um alojamento devem ficar registadas.

P16. Uma conta de alojamento pertence a um servidor. Um servidor pode ter um ou mais alojamentos.

P17. Um alojamento está sempre associado a pelo menos um domínio. Um domínio pode existir sem estar associado a um alojamento.

P18. A Empresa orgulha-se do tempo mínimo que consegue entre o momento da encomenda e a entrega do serviço. Pretende por isso monitorizar essa diferença de tempo.

P19. Os serviços devem estar tabelados com PVP e Preço de custo para que se possam fazer análises de lucro bruto instantâneo.

Outros pressupostos

P20. Pretende-se distinguir o processo online do processo offline. Assim deverá haver um processo de cobrança automatizado online. Em paralelo deverá haver um sistema de emissão de Recibo/facturas offline. Em termos práticos um conjunto de “Recebimentos” online dará origem a uma ou mais facturas emitidas offline.


10

P21. Uma encomenda está associada apenas a um produto. Pelo histórico da empresa, uma encomenda refere-se normalmente a uma conta de alojamento, um domínio ou um alojamento com um domínio. Este último caso, o mais usual, representará a “emissão” de duas encomendas.


11

4. Modelo entidade-relacionamento

4.1 Descrição do modelo Entidade-Relacionamento

Com base nas informações obtidas da empresa e com base em todos os pressupostos descritos no ponto anterior passa-se à fase da especificação do modelo da base de dados. A metodologia será fazer inicialmente uma descrição resumida das entidades mais óbvias encontradas e das respectivas relações. Seguidamente elabora-se o modelo Entidade-Relacionamento (ER).

O modelo ER foi originalmente proposto por Peter Chen em 1976 como um caminho para unificar as relações entre bases de dados. Desde essa altura o modelo evoluiu e nos dias de hoje é amplamente utilizado para o desenho de bases de dados.

Para o profissional que constrói uma base de dados o modelo ER é:

- Facilmente convertido em tabelas relacionais.

- É simples e fácil de entender. Pode por isso ser utilizado pelo designer da base de dados para facilmente comunicar a estrutura do modelo ao utilizador final.

- Pode servir como modelo para o desenvolvimento do sistema de informação.

O modelo ER “vê” o mundo real como uma construção de entidades e associações entre entidades.

Entidades

As entidades são o objecto de dados principal num modelo ER. As entidades são normalmente os conceitos mais evidentes, não abstractos, na análise de um sistema.

As entidades são classificadas como independentes ou dependentes. Alguns autores utilizam a terminologia entidade forte e entidade fraca.


12

Uma entidade independente é toda a que não depende de outra para se identificar. Uma entidade dependente é toda a que necessita de outras para ser identificada.

Uma instância é uma ocorrência individual na entidade.

Entidades especiais

Entidades associativas (ou entidades de intercepção) são entidades usadas para associar duas ou mais entidades de forma a reconciliar uma relação” muitos para muitos”.

Relações

Uma relação representa uma associação entre duas ou mais entidades. O exemplo de uma relação no caso prático estudado seria:

��

Atributos

Os atributos descrevem a entidade à qual estão associados. No modelo relacional a instância de um atributo é um valor. O domínio de um atributo é a a colecção de todos os valores possíveis que o atributo pode assumir.

4.2 Identificação das principais Entidades e Relações

No processo de análise inicial identificaram-se as seguintes entidades: Clientes, Produtos/Serviços (adiante designada por Produtos), Encomendas, Pagamentos, Notas, Servidor.

Principais relações encontradas:

R1. Os Clientes realizam Encomendas


13

R2. Os Clientes realizam Pagamentos referentes a Encomendas

R3. As Encomendas são constituídas por Produtos

R4. Os Produtos podem ser Alojamentos, Domínios ou outros serviços ou produtos.

R5. Cada Encomenda integra apenas um (1) produto

4.3 Construção do modelo ER�

Área comercial (os Clientes)

Associados à entidade CLIENTE encontraram-se os seguintes atributos: id_cliente, Tipo_facturação, Tipo_cliente, Designacao, Morada, Cod_postal, Localidade, País, Num_fiscal, Tel, Fax, Email, Web, data_angariacao, desconto, nome_contacto, função_contacto, Tel_contacto, Fax_contacto, Email_contacto, Skype_contacto, Web_contacto, Obs,

Com uma análise mais aprofundada verificamos que alguns desses atributos são passíveis de ser decompostos em sub-entidades, nomeadamente: País, Tipo_cliente, Contacto (nome, função, tel, fax, email, skype, web) e Tipo_facturação.

Assim ficaríamos com o seguinte modelo ER (por questão de simplificação não se incluíram os atributos):


14

A destacar as seguintes relações:

R1. Os TIPOS CLIENTES agrupam CLIENTES

R2. Os TIPOS FACTURAÇÃO aplica-se a CLIENTES

R3. Os CLIENTES têm um ou mais CONTACTOS

R4. Um CONTACTO pode relacionar-se com diversos CLIENTES (por exemplo um Webdesigner pode ser o contacto de diversos clientes)

R5. Os CLIENTES pertencem a um PAÍS

Área das Vendas

TIPO FACTURAÇÃO

CLIENTES

CONTACTOS

TIPO CLIENTES AgrupamAgrupados

UtilizadaEscolhem

TêmRelacionam-se

Função/Relação

PAÍSES AlbergamResidem


15

O processo de “vendas” inclui as encomendas, as cobranças, os pagamentos e as facturas. O modelo ER assume a forma:

A destacar as seguintes relações:

R1. Os CLIENTES realizam ENCOMENDAS

R2. As ENCOMENDAS dão origem a COBRANÇAS

R3. As COBRANÇAS são pagas pelos CLIENTES

R4. Uma COBRANÇA pode incluir mais do que uma ENCOMENDA

CLIENTES

ENCOMENDAS

COBRANÇAS

FazemSão feitas

PagamPagas

OriginamReferentes

FACTURAS/RECIBOS

OriginamReferentes

RecebemEmitida para


16

R5. Uma COBRANÇA paga dá origem à emissão de uma FACTURA(RECIBO)

R6. Uma FACTURA pode incluir diversas COBRANÇAS pagas

Há um conceito importante a reter neste modelo, as encomendas são automaticamente renovadas, caso o cliente tenha seleccionado essa opção. Assim, o sistema informático a desenvolver irá automaticamente, nas periodicidades escolhidas pelo cliente auto-renovar a encomenda, adequando-a aos preços em vigor e fazendo despoletar as notas de cobrança em conformidade.

Área do Produto/Serviço

A componente dos produtos/serviços oferecidos tem a particularidade de os produtos terem diferentes preços mediante o tipo de cliente (PVP, Revenda, preços especiais, preço de custo).

Originalmente ponderou-se a inclusão de duas entidades para colocação de preços de venda ao público e outra para preços de custo. Verificámos que se considerar-mos a própria empresa como sendo um cliente (cliente interno), poderemos com uma única entidade/relação armazenar os referidos preços.

O modelo ER assume o seguinte esquema:

Outras áreas

Dos pressupostos inicialmente assumidos, verificámos que há alguns que não se adequam à realidade, nomeadamente a necessidade de armazenar os dados de cartões de

TIPO CLIENTES ENCOMENDASPRODUTOS São incluidosIncluiPreços

ValorDesde


17

crédito. Por análise do sistema de comunicações da SIBS e UNICRE verificámos que o sistema é realizado em tempo real, não sendo necessário guardar este tipo de informações.

Incidentes/Notas

Para se armazenarem todos os contactos de pedido de suporte ou pedidos de alterações, desenvolveu-se uma entidade que permite de forma simples, armazenar todos estes contactos para futura referência. É um ponto importante na recolha de informação, pois o histórico de incidentes e actuações na resolução das diversas situações que vão aparecendo, constituem uma informação rica para o suporte técnico quando aparecem situações semelhantes e mesmo na realização de listas de FAQS.

Campanhas

Haverá no modelo relacional a adoptar uma tabela para armazenar os dados e investimentos nas campanhas publicitárias. Esta entidade “campanhas” não se relaciona com nenhuma outra.

CLIENTESNOTAS ReferenteOriginam


18

O modelo ER completo

TIPO FACTURAÇÃO

CLIENTES

CONTACTOS

TIPO CLIENTES AgrupamAgrupados

UtilizadaEscolhem

TêmRelacionam-se

Função/Relação

PAÍSES AlbergamResidem

ENCOMENDAS

COBRANÇAS

FazemSão feitas

PagamPagas

OriginamReferentes

PRODUTOS

FACTURAS/RECIBOS

São incluidosInclui

OriginamReferentes

RecebemEmitida para

Preços

ValorDesde

NOTAS ReferenteOriginam


19

Outra representação do modelo

Com o DBdesigner 4 conseguimos facilmente obter o seguinte modelo, já mais normalizado.


20

5. Modelo relacional

Obtido o modelo ER é fácil construir o modelo relacional. O conceito de entidade e de atributo tem uma clara correspondência com o conceito de tabela.

Quando se transforma um modelo ER num conjunto de tabelas, é por vezes necessário realizar alterações na estrutura das tabelas, originadas pela observação de determinados pormenores práticos que por vezes não são correctamente perceptíveis no modelo ER. Da mesma forma poderá ser necessário fazer alguns ajustes nas tabelas resultantes de relações no modelo ER.

O modelo relacional demonstra-se normalmente da seguinte forma:

PAISES(cod_pais:varchar(2),pais:varchar(50),língua:varchar(50),imposto:bool)

Dada a dimensão grande de muitas das tabelas descrevem-se pormenorizadamente em formato tabular o modelo relacional construído com base no modelo ER.

Área Comercial

Clientes

Coluna Tipo de Dados Chave AutoInc

id_cliente INTEGER Sim Sim

Cod_Tipo_facturação VARCHAR(2)

Cod_pSims VARCHAR(2)

Cod_tipo_cliente VARCHAR(2)

Designacao VARCHAR(200)

Morada1 VARCHAR(200)


21

Morada2 VARCHAR(200)

Cod_postal VARCHAR(10)

Localidade VARCHAR(100)

Num_fiscal VARCHAR(15)

Tel VARCHAR(20)

Fax VARCHAR(20)

EmSiml VARCHAR(100)

Web VARCHAR(100)

data_angariacao DATETIME

desconto REAL

Clientes_tipo


Cod_tipo_cliente VARCHAR(2) Sim

Tipo_cliente VARCHAR(15)

Paises


Cod_pais VARCHAR(2) Sim

Pais VARCHAR(50)


22

lingua VARCHAR(50)

imposto BOOL

Tipo_facturacao


Cod_Tipo_facturação VARCHAR(2) Sim

Tipo_facturacao VARCHAR(15)

Contactos


id_contacto INTEGER Sim Sim

Nome VARCHAR(100)

Tel VARCHAR(15)

Fax VARCHAR(15)

EmSiml VARCHAR(50)

Skype VARCHAR(15)

Web VARCHAR(100)

Obs TEXT

Relacoes



23

id_cliente INTEGER Sim

id_contacto INTEGER Sim

Relação VARCHAR(50)

Outros

Campanhas


id_campanhas INTEGER Sim Sim

designação VARCHAR(50)

data_inicio DATE

data_fim DATE

valor_investido REAL

descrição TEXT

Notas


id_suporte INTEGER Sim Sim

id_cliente INTEGER


24

data_hora_contacto DATETIME

titulo VARCHAR(100)

descrição_contacto TEXT

procedimento_adoptado TEXT

data_hora_resolução DATETIME

tecnico VARCHAR(100)

Área de Produto/Serviço

Produtos


id_produto INTEGER Sim Sim

cod_tipo_produto VARCHAR(2)

designacao VARCHAR(200)

descricao TEXT

periodicidade INTEGER

Produtos_tipo



25

cod_tipo_produto VARCHAR(2) Sim

Tipo_produto VARCHAR(200)

Precos


id_produto INTEGER Sim

desde DATE Sim

Cod_tipo_cliente VARCHAR(2) Sim

Preço REAL

IVA REAL

Área de Vendas

Encomendas


id_encomenda INTEGER Sim Sim

id_cliente INTEGER

id_produto INTEGER

id_estado VARCHAR(2)


26

Data_Hora_encomenda DATETIME

Data_Hora_entrega DATETIME

Pormenor1 VARCHAR(200)

Pormenor2 VARCHAR(200)

Obs TEXT

IP_origem TEXT

URL_origem VARCHAR(200)

palavra_pesquisa VARCHAR(200)

data_renovação DATE

aviso_sms BOOL

aviso_emSiml BOOL

renovação_auto BOOL

Estado


id_estado VARCHAR(2) Sim

Estado VARCHAR(20)

Descrição VARCHAR(200)

Tipos_pagamento


27


id_tipos_pagamento INTEGER Sim

tipo_pagamento VARCHAR(50)

Cobrancas_Pagamentos


id_cobrança INTEGER Sim Sim

id_facturarecibo INTEGER

id_encomenda INTEGER

id_cliente INTEGER

id_tipos_pagamento INTEGER

estado_pagamento INTEGER

data_inicio_cobrança DATE

data_validade DATE

data_pagamento TEXT

valor REAL

observações TEXT

FacturaRecibo



28

id_facturarecibo INTEGER Sim Sim

id_cliente INTEGER

data_emissão DATE

valor_liquido REAL

IVA REAL

Total REAL


29

6. Normalização

A normalização é um processo que consiste em estruturar a informação em tabelas na forma que pode ser considerada mais adequada do ponto de vista das operações a executar sobre a informação armazenada, evitando redundâncias desnecessárias e certos problemas associados à inserção, eliminando e actualização de dados.

O modelo relacional previa inicialmente a existência de três formas normais, a 1ª Forma Normal (1FN), a 2ª Forma Normal (2FN) e a 3ª Forma Normal (3FN).

Em pormenor:

1FN: Uma tabela encontra-se na 1FN se todos os seus atributos estiverem definidos em domínios que contenham apenas valores atómicos.

2FN: Uma tabela encontra-se na 2FN se está na 1FN e se todos os atributos que não pertencem à chave, dependem da chave através da dependência funcional elementar.

3FN: Uma tabela encontra-se na 3FN está na 2FN e se nenhum dos atributos que fazem parte da chave pode ser funcionalmente dependente de qualquer combinação dos restantes.

Na prática, os procedimentos de normalização consideram-se satisfatórios se as tabelas atingirem a 3FN.

A normalização foi aplicada neste trabalho quando se decompôs a tabela de clientes em sub-tabelas.

A tabela CLIENTES era constituída por atributos que continham conjuntos de conjuntos, nomeadamente, os PAISES, o TIPO de FACTURAÇÃO, CLIENTE TIPO. No caso da tabela CONTACTOS, originalmente integrada na tabela CLIENTES, a opção foi possibilitar que um cliente tivesse mais de que um contacto.


30

7. Criação da Base de Dados em MYSQL

Seguem as instruções SQL para criação das tabelas no MYSQL.

PRODUTOS_TIPO

CREATE TABLE Produtos_tipo (

cod_tipo_produto VARCHAR(2) NOT NULL,

Tipo_produto VARCHAR(200) NULL,

PRIMARY KEY(cod_tipo_produto));

CONTACTOS

CREATE TABLE Contactos (

id_contacto INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

Nome VARCHAR(100) NULL,

Tel VARCHAR(15) NULL,

Fax VARCHAR(15) NULL,

Email VARCHAR(50) NULL,

Skype VARCHAR(15) NULL,

Web VARCHAR(100) NULL,

Obs TEXT NULL,

PRIMARY KEY(id_contacto));

PAÍSES

CREATE TABLE Paises (

Cod_pais VARCHAR(2) NOT NULL,

pais VARCHAR(50) NULL,

lingua VARCHAR(50) NULL,

imposto BOOL NULL,

PRIMARY KEY(Cod_pais));


31

ESTADO

CREATE TABLE Estado (

id_estado VARCHAR(2) NOT NULL,

Estado VARCHAR(20) NULL,

Descrição VARCHAR(200) NULL,

PRIMARY KEY(id_estado));

TIPO_FACTURAÇÃO

CREATE TABLE Tipo_facturacao (

Cod_Tipo_facturação VARCHAR(2) NOT NULL,

Tipo_facturacao VARCHAR(15) NULL,

PRIMARY KEY(Cod_Tipo_facturação));

CAMPANHAS

CREATE TABLE Campanhas (

id_campanhas INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

designação VARCHAR(50) NULL,

data_inicio DATE NULL,

data_fim DATE NULL,

valor_investido REAL NULL,

descrição TEXT NULL,

PRIMARY KEY(id_campanhas));


32

TIPOS_PAGAMENTOS

CREATE TABLE Tipos_pagamento (

id_tipos_pagamento INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

tipo_pagamento VARCHAR(50) NULL,

PRIMARY KEY(id_tipos_pagamento));

CLIENTES_TIPO

CREATE TABLE Clientes_tipo (

Cod_tipo_cliente VARCHAR(2) NOT NULL,

Tipo_cliente VARCHAR(15) NOT NULL,

PRIMARY KEY(Cod_tipo_cliente));

PRODUTOS

CREATE TABLE Produtos (

id_produto INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

cod_tipo_produto VARCHAR(2) NOT NULL,

designacao VARCHAR(200) NULL,

descricao TEXT NULL,

periodicidade INTEGER UNSIGNED NULL,

PRIMARY KEY(id_produto),

FOREIGN KEY(cod_tipo_produto)

REFERENCES Produtos_tipo(cod_tipo_produto)

ON DELETE NO ACTION

ON UPDATE NO ACTION);


33

PREÇOS

CREATE TABLE Precos (

id_produto INTEGER UNSIGNED NOT NULL,

desde DATE NOT NULL,


Preço REAL NOT NULL,

IVA REAL NULL,

Preço_custo REAL NOT NULL,

PRIMARY KEY(id_produto, desde, Cod_tipo_cliente),

FOREIGN KEY(id_produto)

REFERENCES Produtos(id_produto)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

FOREIGN KEY(Cod_tipo_cliente)

REFERENCES Clientes_tipo(Cod_tipo_cliente)

ON DELETE RESTRICT

ON UPDATE CASCADE);


34

CLIENTES

CREATE TABLE Clientes (

id_cliente INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

Cod_Tipo_facturação VARCHAR(2) NOT NULL,

Cod_pais VARCHAR(2) NOT NULL,


Designacao VARCHAR(200) NULL,

Morada1 VARCHAR(200) NULL,

Morada2 VARCHAR(200) NULL,

Cod_postal VARCHAR(10) NULL,

Localidade VARCHAR(100) NULL,

Num_fiscal VARCHAR(15) NULL,

Tel VARCHAR(20) NULL,

Fax VARCHAR(20) NULL,

Email VARCHAR(100) NULL,

Web VARCHAR(100) NULL,

data_angariacao DATETIME NULL,

desconto REAL NULL,

PRIMARY KEY(id_cliente),

FOREIGN KEY(Cod_tipo_cliente)

REFERENCES Clientes_tipo(Cod_tipo_cliente)

ON DELETE RESTRICT

ON UPDATE CASCADE,

FOREIGN KEY(Cod_pais)

REFERENCES Paises(Cod_pais)

ON DELETE RESTRICT

ON UPDATE CASCADE,

FOREIGN KEY(Cod_Tipo_facturação)

REFERENCES Tipo_facturacao(Cod_Tipo_facturação)

ON DELETE RESTRICT

ON UPDATE CASCADE);


35

ENCOMENDAS

CREATE TABLE Encomendas (

id_encomenda INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

id_cliente INTEGER UNSIGNED NOT NULL,

id_produto INTEGER UNSIGNED NOT NULL,

id_estado VARCHAR(2) NOT NULL,

Data_Hora_encomenda DATETIME NULL,

Data_Hora_entrega DATETIME NULL,

Pormenor1 VARCHAR(200) NULL,

Pormenor2 VARCHAR(200) NULL,

Preço VARCHAR(200) NULL,

Preço_custo VARCHAR(200) NULL,

Obs TEXT NULL,

IP_origem TEXT NULL,

URL_origem VARCHAR(200) NULL,

palavra_pesquisa VARCHAR(200) NULL,

data_renovação DATE NULL,

aviso_sms BOOL NULL,

aviso_email BOOL NULL,

renovação_auto BOOL NULL,

PRIMARY KEY(id_encomenda),

FOREIGN KEY(id_cliente)

REFERENCES Clientes(id_cliente)

ON DELETE NO ACTION


FOREIGN KEY(id_estado)

REFERENCES Estado(id_estado)

ON DELETE NO ACTION


FOREIGN KEY(id_produto)

REFERENCES Produtos(id_produto)

ON DELETE NO ACTION


36


FACTURA_RECIBO

CREATE TABLE FacturaRecibo (

id_facturarecibo INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,


data_emissão DATE NULL,

valor_liquido REAL NULL,

IVA REAL NULL,

Total REAL NULL,

PRIMARY KEY(id_facturarecibo),



ON DELETE RESTRICT

ON UPDATE RESTRICT);

NOTAS

CREATE TABLE Notas (

id_suporte INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,


data_hora_contacto DATETIME NULL,

titulo VARCHAR(100) NULL,

descrição_contacto TEXT NULL,

procedimento_adoptado TEXT NULL,

data_hora_resolução DATETIME NULL,

tecnico VARCHAR(100) NULL,

PRIMARY KEY(id_suporte),



ON DELETE RESTRICT


37

ON UPDATE CASCADE);

RELAÇÕES

CREATE TABLE Relacoes (


id_contacto INTEGER UNSIGNED NOT NULL,

Relação VARCHAR(50) NULL,

PRIMARY KEY(id_cliente, id_contacto),



ON DELETE RESTRICT

ON UPDATE CASCADE,

FOREIGN KEY(id_contacto)

REFERENCES Contactos(id_contacto)

ON DELETE RESTRICT

ON UPDATE CASCADE);


38

COBRANÇAS_PAGAMENTOS

CREATE TABLE Cobrancas_Pagamentos (

id_cobrança INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

id_facturarecibo INTEGER UNSIGNED NOT NULL,

id_encomenda INTEGER UNSIGNED NOT NULL,


id_tipos_pagamento INTEGER UNSIGNED NOT NULL,

estado_pagamento INTEGER UNSIGNED NULL,

data_inicio_cobrança DATE NULL,

data_validade DATE NULL,

data_pagamento TEXT NULL,

valor REAL NULL,

observações TEXT NULL,

PRIMARY KEY(id_cobrança),



ON DELETE RESTRICT

ON UPDATE CASCADE,

FOREIGN KEY(id_tipos_pagamento)

REFERENCES Tipos_pagamento(id_tipos_pagamento)

ON DELETE NO ACTION


FOREIGN KEY(id_encomenda)

REFERENCES Encomendas(id_encomenda)

ON DELETE NO ACTION


FOREIGN KEY(id_facturarecibo)

REFERENCES FacturaRecibo(id_facturarecibo)

ON DELETE NO ACTION



39

8. Consultas SQL

Seguem algumas instruções SQL para obtenção de informações:

Quantas encomendas por ano, mês?

SELECT year(data_hora_encomenda) as ano,month(data_hora_encomenda) as mes,count(*) as total

FROM encomendas

GROUP BY ano,mes

Serviços disponibilizados a determinado cliente?

SELECT produtos.designacao

FROM (encomendas, clientes, produtos)

WHERE encomendas.id_produto=produtos.id_produto and encomendas.id_cliente=clientes.id_cliente and clientes.id_cliente=1

Lista de cobranças por pagar?

SELECT * FROM cobrancas_pagamentos where estado_pagamento=0

Encomendas pendentes?

SELECT * FROM encomendas where id_estado<3

Encomendas com status de "Em pagamento"?

SELECT * FROM encomendas where id_estado=2

Tempo máximo entre encomenda e entrega do serviço?

SELECT id_encomenda, timediff(data_hora_entrega,data_hora_encomenda) as tempo FROM encomendas e


40

Total de encomendas por fonte publicitária?

SELECT url_origem, count(*)

FROM encomendas group by url_origem

Total de encomendas por palavra de pesquisa?

SELECT palavra_pesquisa, count(*)

FROM encomendas group by palavra_pesquisa

Domínios sem conta de alojamento?

SELECT pormenor1, count(pormenor1) as total

FROM encomendas

GROUP BY pormenor1

HAVING total=1

Nota: No campo “pormenor1” fica guardado o nome do domínio, quer seja a encomenda de um domínio quer seja a encomenda de uma alojamento. Se houver domínio + alojamento encontram-se dois registos com o mesmo domínio. Se for apenas o domínio aparece apenas um registo.

Lucro bruto mensal?

SELECT concat(year(data_hora_encomenda) ,"-",right(concat("00", month(data_hora_encomenda)),2)) as anomes, sum(preço-preço_custo) as lucro_bruto

FROM encomendas

GROUP BY anomes

Nota: Ao desenvolver esta instrução SQL constatou-se que para obter a diferença entre o preço de venda e o preço de custo seria necessária a aplicação de uma estrutura complexa de instruções SQL encadeadas. Por este motivo optou-se por adicionar mais um atributo à entidade “Preços” com o preço de custo associado a um produto. Desta forma a obtenção desta informação “preciosa” é imediata e muito mais eficaz. Alterou-se igualmente a tabela “Encomendas” de forma a incluir os dois preços referidos. Esta alteração já se reflecte no modelo relacional apresentado nos pontos anteriores.


41

Domínios a renovar no próximo mês?

SELECT pormenor1

FROM encomendas, produtos

WHERE produtos.id_produto=encomendas.id_produto and cod_tipo_produto="D" and month(date_add(now(),INTERVAL 1 Month))=month(data_renovação)

Domínios por extensão (".com", ".net", ".eu", etc)?

SELECT cod_tipo_produto, produtos.designacao, encomendas.pormenor1

FROM produtos, encomendas

WHERE encomendas.id_produto=produtos.id_produto

GROUP BY produtos.designacao, encomendas.pormenor1

HAVING cod_tipo_produto="D"

Lucro bruto por tipo de produto e por ano?

SELECT year(data_hora_encomenda) as ano, tipo_produto, sum(preço-preço_custo) as lucro

FROM encomendas, produtos, produtos_tipo

WHERE encomendas.id_produto=produtos.id_produto and produtos_tipo.cod_tipo_produto=produtos.cod_tipo_produto

GROUP BY ano, tipo_produto

Lista de revendedores?

SELECT *

FROM clientes

WHERE cod_tipo_cliente like 'R%'


42

Rentabilidade por revendedor por ano?

SELECT clientes.designacao, year(data_hora_encomenda) as ano, sum(preço-preço_custo) as lucro

FROM encomendas, clientes

WHERE encomendas.id_cliente=clientes.id_cliente and clientes.cod_tipo_cliente like "R%"

GROUP BY clientes.designacao, ano

Notas retiradas por Cliente?

SELECT Titulo, Descrição_contacto, Procedimento_adoptado

FROM clientes, notas

WHERE notas.id_cliente=clientes.id_cliente

Notas retiradas com determinada palavra?

SELECT Titulo, Descrição_contacto, Procedimento_adoptado

FROM notas

WHERE notas.titulo like “%palavra%” or notas.descriçao_contacto like “%palavra%” or notas.procedimento_adoptado like “%palavra%”

Número de Clientes por País?

SELECT pais, count(*) as total

FROM paises, clientes

WHERE paises.cod_pais=clientes.cod_pais

GROUP BY pais


43

9. Conteúdos Consultados

- Conteúdos da disciplina disponibilizados no MOODLE.

- Database Design Using Entity-Relationship Diagrams

by Sikha Bagui and Richard Earp ISBN:0849315484

- Desenho de bases de dados e linguagem SQL em Access

Edições CTI, Rui Carriço e José Carriço. ISBN.972-8401-48-5

Trabalho realizado por

Manuel José Ferreira Monteiro

Disciplina

Bases de Dados e Programação

Docente

Professor Doutor Luis Torgo

Mestrado

Análise de Dados e Sistemas de Apoio à Decisão

Faculdade de Economia - Universidade do Porto

17 de Fevereiro de 2006

Trab bd ficticia

Documents

Transcript of Trab bd ficticia