Relatorio BD1516-Grupo28

Universidade do Minho
Escola de Engenharia
Mestrado Integrado em Engenharia Informtica
Unidade Curricular de
Bases de Dados
Ano Lectivo de 2015/2016
BelaPadaria
Clia Natlia Lemos Figueiredo (a67637),

Mrcia Maria Fernandes da Costa (a67672),
Pedro Miguel da Rocha Ribeiro (a67717),
Xavier Neves Francisco (a67725)
Janeiro, 2016
Data de Recepo
Responsvel
Avaliao
Observaes
BelaPadaria
Clia Natlia Lemos Figueiredo (a67637),

Mrcia Maria Fernandes da Costa (a67672),
Pedro Miguel da Rocha Ribeiro (a67717),
Xavier Neves Francisco (a67725)
<<Janeiro, 2016>>
<</opcional Dedicatria>>
Resumo
O documento contm toda a informao sobre o processo de elaborao de uma
arquitetura de base de dados, que ser a base para a informatizao do processo de fabrico e
venda de uma empresa produtora de po.
Inicialmente feita a contextualizao do problema apresentado, seguindo-se da
anlise do caso de estudo em questo. Ainda numa parte introdutria descrita a motivao
que levou a empresa a optar pela mudana do modo como era registada a informao relativa
ao processo de produo, assim como os objetivos a atingir com essa mesma mudana.
Esta
primeira
parte
do
relatrio
do
projeto
incluir
os
seguintes
pontos:
contextualizao do projeto, motivao e objetivos, anlise de requisitos e a estrutura do

relatrio.
Durante a fase de modelao conceptual da base de dados sero identificados, com base nos
requisitos, as entidades envolvidas no sistema e os seus relacionamentos. De seguida, sero
identificados os atributos associados s entidades e/ou aos relacionamentos. Em cada
entidade sero apresentadas as suas chaves candidatas e a escolha da sua chave primria.
Aps concludo o modelo conceptual e antes de prosseguir com o modelo lgico, ser feita a
eleio do motor de base de dados, onde futuramente ser implementada toda a estrutura que
derivar dos vrios desenhos que sero calculados durante todo o processo.
Com base na segunda fase da metodologia, ser derivado o modelo lgico
correspondente ao modelo conceptual. De seguida sero validadas as relaes atravs da
normalizao, a qual corresponde a um dos passos mais importantes da metodologia. Aps
verificar que o modelo est normalizado sero validadas as relaes atravs do uso de
transaes do utilizador, assim como verificadas as restries de integridade.
rea de Aplicao: Desenho e arquitetura de Sistemas de Bases de Dados.

Palavras-Chave: Bases de dados relacionais, anlise de requisitos, entidades, atributos,
relacionamentos, metodologia, modelo conceptual, modelo lgico, modelo fsico, SGBD
ndice
1. Introduo
1.1. Contextualizao
1.2. Apresentao do Caso de Estudo
1.3. Motivao e Objetivos
1.4. Estrutura do Relatrio
2. Anlise e levantamento de requisitos
3. Modelo Conceptual da Base de Dados
3.1. Identificar as entidades do problema
3.1.1 Cliente
3.1.2 Funcionrio
3.1.3 Pedido
3.1.4 Produto
3.1.5 Dicionrio de dados das entidades
3.2. Identificar tipos de relacionamentos
10
3.2.1 Dicionrio de dados dos relacionamentos
10
3.3. Identificar e relacionar atributos com as entidades e tipos de relacionamentos/

Determinar domnios de atributo
11
3.3.1 Dicionrio de dados dos atributos das entidades
11
3.3.2 Dicionrio de dados dos atributos das relaes
13
3.4. Determinar chaves candidatas, primrias e alternadas
14
3.5. Considerar o uso de modelao avanada
15
3.6. Verificar que no existem redundncias no modelo
15
3.7. Validar Modelo com perguntas do utilizador
16
3.8. Rever e validar o Modelo com o Utilizador
18
4. Modelo Lgico
19
4.1. Derivao das relaes para o modelo lgico
19
4.2. Validao das relaes atravs da normalizao
22
4.2.1 1FN 1 Forma Normal
22
22
23
4.3. Validao das relaes atravs das transaes dos utilizadores
23
ii
4.4. Anlise das restries de integridade
24
4.5. Reviso do modelo lgico com o utilizador
28
4.6. Anlise do crescimento futuro
29
5. Modelo Fsico
33
5.1. Traduo do modelo lgico para o SGBD escolhido
33
5.1.1 Desenho das relaes base
33
5.1.2 Desenho das representaes dos dados derivados
38
5.1.3 Desenho das restries gerais
38
5.2. Organizao dos ficheiros e ndices
40
5.2.1 Anlise de transaes
40
5.2.2 Escolha da organizao dos ficheiros
42
5.2.3 Escolha dos ndices
42
5.2.4 Estimativa de espao em disco necessrio
43
5.3. Desenho das vistas de utilizadores
44
5.4. Mecanismos de segurana
45
5.5. Considerao de introduo de redundncia controlada
47
5.6. Monitorizar e afinar o sistema operativo
47
6. Ferramentas utilizadas
48
7. Concluses e Trabalho Futuro
49
Anexos
I.
Anexo 1 Script completo da criao do esquema
53
II.
Anexo Script completo do Povoamento da BelaPadaria
59
iii
ndice de Figuras
Figura 1 - Esquema conceptual
Figura 2 - Relacionamento entre Entidades
10
Figura 3 - Diagrama ER com as chaves primrias adicionadas
14
Figura 4 - Modelo Lgico
19
Figura 5 - Excerto da script criao da tabela Clientes
27
Figura 6 - Excerto da script criao da tabela Funcionarios
27
Figura 7 Excerto da Criao da script criao da tabela Produtos
28
Figura 8 - Excerto da script de criao da tabela Pedidos
28
Figura 9 - Script da criao do gatilho "AtualizaValor"
38
Figura 10 - Criao de um gatilho que permite verificar o limite de idades 39

Figura 11 Transao 1 Criao do procedimento registarPedido
41
Figura 12 Criao do procedimento atualizarStockFromFunc
41
Figura 13 Criao do procedimento substiuFun
42
Figura 14 - Criao de ndices
43
Figura 15 - Criao de uma Vista com o preario, visivel para os clientes 45

Figura 16 - Criao de uma vista coma informao dos horarios dos funcionrios
45
Figura 17 - Criao de uma vista contendo a informao dos clientes
45
Figura 18 - Criao de uma vista contendo a informao da relao cliente compra

45
iv
ndice de Tabelas
Tabela 1 - Dicionrio de dados das entidades
Tabela 2 - Dicionrio de dados dos relacionamentos
10
Tabela 3 - Dicionrio de dados dos atributos das entidades
13
Tabela 4 - Dicionrio de dados dos atributos dos relacionamentos
13
Tabela 5 - Tipos de dados e tamanhos em Sql Server
30
Tabela 6 - Tamanho inicial para a tabela Funcionarios
30
Tabela 7 - Tamanho inicial para a tabela Clientes
30
Tabela 8 - Tamanho inicial para a tabela Produtos
31
Tabela 9 - Tamanho inicial para a tabela Pedidos
31
Tabela 10 - Tamanho inicial para a tabela FuncionariosProdutos
31
Tabela 11 - Tamanho inicial para a tabela FuncionariosPedidos
31
Tabela 13 - Tamanho inicial para a tabela PedidosProdutos
32
1. Introduo
Este primeiro capitulo tem como objetivo apresentar uma breve introduo ao projeto a
realizar. Sendo assim, necessrio definir o contexto no qual se desenvolve o caso de estudo,
seguido da sua descrio. tambm importante perceber os motivos que levaram criao da
BelaPadaria assim como os objetivos pretendidos.
Ainda numa parte introdutria ao nosso trabalho prtico, vamos definir o contexto no
qual se desenvolve o caso de estudo e posteriormente descrev-lo.
Vamos tambm abordar alguns motivos que nos levaram escolha e posterior
desenvolvimento da BelaPadaria, incluindo desta forma, uma anlise do caso de estudo.
Relativamente a segunda parte do nosso projeto ser apresentado o modelo lgico
correspondente ao modelo conceptual. Faremos uma anlise e validao das relaes atravs
da normalizao e ainda de seguida faremos a validao das relaes construindo o mapa das
transaes e respetivas anotaes e concluses finais.
1.1. Contextualizao
A panificao talvez uma das artes culinrias mais antigas, os primeiros relatos sobre
a produo e consumo de po pelo homem datam do ano 8.000 a.C. quando uma
massa de
farinha de trigo (obtida pela moagem rudimentar com pedras) seria misturada com gua e
cozinhada em pedras aquecidas. Atualmente o processo de produo de po est bastante
diferente devido grande evoluo e concorrncia no mundo da indstria, existe uma grande
oferta tecnolgica e inovadora que permite s empresas oferecer um servio com qualidade e
diversificao aos clientes. O facto de as empresas encontrarem equipamentos adaptados
sua necessidade, cujo investimento muito alto, quase todas as padarias tm os mesmos
produtos, sendo artesanal e padronizado, o que fica muito claro que a maioria dos produtos
pr- mistura, com acabamento no ponto de venda, parecendo os mesmos em todas as
padarias. apostando nesses mercados sempre em evoluo e procurando disponibilizar
produtos a preo mais baixo que a concorrncia, que surge a BelaPadaria.
A empresa BelaPadaria dedica-se ao fabrico de po e outros derivados para venda no
setor alimentar. A empresa efetua todo o processo de fabrico, desde a aquisio da matria1
prima at concluso do processo de fabrico de po e outros derivados para posterior venda,

incluindo ainda, um controlo minucioso sobre a qualidade do mesmo.
Os produtos produzidos destinam-se venda direta ao consumidor final.
1.2. Apresentao do Caso de Estudo

A padaria efetua todo o processo de fabrico desde a aquisio da matria-prima at
concluso do po em si para posterior venda. Est ainda includo um controlo minucioso sobre
a qualidade do po. A empresa est dividida em vrios sectores nomeadamente o sector
financeiro, recursos humanos, compra de matrias-primas, fabrico de po e entrega. Apenas
ser alvo de estudo os sectores de fabrico de po e a sua respetiva entrega.
Ser tambm englobado no problema, a gesto dos operrios que fazem parte deste
processo de produo. Assim, operrios, supervisores e chefes de seco da produo sero
abrangidos, mas todos os trabalhadores de outras seces no faro parte do sistema a
desenvolver.
O processo de construo do po segue uma sequncia que vamos passar a
descrever: na primeira fase, um operrio segue uma determinada receita para fazer a massa
do po; aps estar concluda, a massa dividida e modelada na forma final em que o po
vendido. Seguidamente colocado no forno onde cozido temperatura adequada para
garantir a textura caracterstica da padaria em estudo.
Os pes concludos so enviados para o controlo de qualidade, porm este processo
no ser alvo de estudo, para posteriormente o po ser vendido na loja por um funcionrio
responsvel.
Neste documento, todo este processo ser alvo de um estudo profundo, documentado
atravs de uma pormenorizada anlise de requisitos, para de acordo com a metodologia
traada, ser ento desenvolvido um sistema que cumpra todos os objetivos definidos.
1.3. Motivao e Objetivos

Motivao
Os portugueses tal como a maioria das culturas pelo mundo tm o po presente na sua
alimentao e no passam uma refeio sem saborear uma boa fatia. Em Portugal, a tradio
de comer po j antiga no tempo e um dos alimentos que est na base da alimentao
portuguesa. Feito base de trs cereais milho, centeio e trigo diferente de regio para
regio tanto na forma, como na cor, no gosto ou na textura do miolo, sendo usado em pratos
tradicionais ou at em doces.
2
Foi o facto de ser um alimento simples e to famoso que nos fez pensar em criar uma
base de dados para a gesto mais eficiente de uma padaria. Visto que o po do consumo
comum da comunidade portuguesa, achamos que uma empresa deste tipo daria lucro e teria
margem para crescer.
Devido grande adeso esperada por parte de potenciais clientes, esta rea d
bastante lucro empresa, e consequentemente, o sucesso pretendido.
Objetivos
Aps a concluso deste projeto e da ingresso da BelaPadaria no mercado,
esperado que se consiga atingir um determinado nmero de objetivos. Assim, um dos objetivos
pretendidos que a empresa consiga progredir no mercado, obtendo sempre um nmero cada
vez mais elevado de clientes ao longo do tempo. Para o aumento da produo esperado,
espera-se conseguir atingir um nvel elevado no que diz respeito rapidez e organizao de
todos os membros da empresa.
Surge tambm a necessidade de
diversificao de ofertas que temos para a
comunidade. Pretende-se que sejamos reconhecidos como os mais econmicos e com mais
qualidade. Pretende-se tambm que os servios oferecidos sejam cada vez mais e melhores.
Outro objetivo seria proporcionar ao cliente um bom atendimento, para alm dos objetivos
mencionados, pretende-se que a empresa tenha facilidade no acesso e gesto de informao
sobre clientes, ofertas, faturas e empregados.
1.4. Estrutura do Relatrio

Este relatrio descreve detalhadamente, o processo de estudo, conceo e
implementao da base de dados que servir de suporte BelaPadaria, seguindo a
metodologia proposta no livro Database Systems - A Practical Approach to Design,
Implementation and Management 4 Edio (Connolly e Begg, 2005).
Assim sendo o documento est organizado em sete captulos, sendo que o primeiro
est a ser abordado e trata do processo de conhecimento do caso de estudo, mais
especificamente, a contextualizao do caso de estudo, a apresentao do mesmo, a
motivao para que o mesmo seja trabalhado e por fim os objetivos pretendidos com a
materializao da soluo do caso de estudo.
O segundo captulo aborda o levantamento de requisitos que ser a base para todo o
resto do trabalho a desenvolver. Assim no terceiro captulo teremos o desenvolvimento do
modelo conceptual que acontece diretamente a partir do levantamento de requisitos. O modelo
3
conceptual ser devidamente documentado assim como testado para os requisitos

considerados.
O quarto captulo dedicado ao modelo lgico, sendo que na primeira seco se
apresenta a derivao das relaes do modelo conceptual para este novo modelo. Validaremos
as relaes atravs da normalizao. Estas relaes so na seco seguinte validadas atravs
das transaes. Neste captulo feita tambm a validao das restries de integridade do
sistema e uma reviso do modelo com o utilizador e uma anlise do crescimento futuro da base
de dados.
No quinto captulo passa-se para o modelo fsico onde na Seco 5.1 feita a traduo
do modelo anterior para o SGBD escolhido. Seguem-se trs subseces com o desenho das
relaes base do modelo, das representaes dos dados derivados e das restries gerais
respetivamente. tambm apresentada a organizao de ficheiros e ndices do modelo. Esta
seco est dividida na anlise de transaes, escolha da organizao dos ficheiros e de
ndices e termina com uma estimativa do espao em disco necessrio para o sistema
desenvolvido. Faremos tambm o desenho das vistas de utilizadores. O captulo finalizado
apresentado os mecanismos de segurana do sistema, uma considerao da introduo de
redundncia no modelo e uma monitorizao e afinao do sistema operativo.
No sexto captulo so apresentadas as ferramentas utilizadas ao longo do
desenvolvimento deste projeto. Finalmente realizada uma apreciao crtica sobre o trabalho
final, destacando os pontos fortes e fracos do mesmo e o trabalho que futuramente poder ser
desenvolvido. A bibliografia pode ser consultada nas ltimas pginas deste documento.
Por ltimo, trataremos das concluses finais do nosso projeto.
2. Anlise e levantamento de requisitos

Esta fase do desenvolvimento muito importante para definir detalhadamente os
requisitos aos quais o nosso sistema deve responder. O sistema em anlise corresponde ao
processo de fabrico de produtos de panificao. Neste fabrico esto envolvidos funcionrios
que executam todas as tarefas necessrias para o fabrico e venda do po.
O domnio da base de dados, que foi pensado para este projeto, abrange os produtos
venda, o prprio registo das vendas, os clientes e os funcionrios da empresa.
De seguida apresentamos os requisitos do funcionamento da empresa do caso em
estudo:
Produtos
O sistema atribuir automaticamente a cada produto registado, um identificador nico
Cada produto tem um nome.
Todos os produtos devero estar guardados no sistema e podero ser posteriormente

adicionados novos.
Cada produto confecionado por um funcionrio
A cada produto est associado um stock
Cada produto tem um tempo de durao de confeo
O preo de um produto dever ser maior do que 0.
Os Produtos faro parte de um pedido solicitado pelo cliente
Clientes
Cada cliente ter um nmero sequencial e nico, identificando o cliente de forma

inequvoca.
Cada cliente efetua um ou mais pedidos
Cada cliente receciona todos os produtos que solicitou no seu pedido
No existem limites de idades para o atendimento a clientes
Um cliente pode ou no efetuar registo com os seguintes dados: nmero do Carto de

Cidado, nmero de identificao fiscal (nif), nome completo, morada (rua, cdigopostal e respetivo concelho), data de nascimento e contactos (telemvel e e-mail).
O nmero do Carto de Cidado e o nmero de identificao fiscal devem ser nicos.
Funcionrios
O sistema atribuir automaticamente a cada funcionrio que se registe, um nmero de

identificao nico entre todos os funcionrios.
Um funcionrio ter os seguintes dados registados: nmero do carto de cidado

nico, nmero de identificao fiscal nico, NIB nico, nome, morada (nmero da porta,
rua, cdigo-postal, freguesia e respetivo concelho e distrito), data de nascimento e
telefone e e-mail e horrio.
Um funcionrio ter um salrio decidido pelo gestor da empresa.
Os funcionrios podem confecionar mais do que um produto ou a registar mais do que

um pedido.
Todos os funcionrios devero estar registados no sistema.
Para se registar, um funcionrio ter de fornecer todos os seus dados pessoais,

nomeadamente todos os requisitos pedidos pelo sistema para registo descritos no
primeiro ponto
Para se registar, um funcionrio dever ter idade igual ou superior a 18 anos e inferior
a 65 anos.
Pedidos
Cada pedido registado por um nmero identificador nico.
Os pedidos podem ser feitos por clientes registados ou no
Os pedidos especificam a quantidade e os tipos de produtos que o cliente est a

adquirir.
O valor de um pedido a soma dos preos de cada produto.
Cada pedido tem uma hora e uma data de registo de pedido
Cada pedido registado por um funcionrio
A cada pedido est associado um e somente um cliente
Um pedido tem um ou mais produtos
3. Modelo Conceptual da Base de Dados

A modelao conceptual a primeira das trs principais fases da metodologia utilizada,
e consiste no processo de construo de um modelo de dados a partir de uma anlise
detalhada aos requisitos. Este modelo completamente independente de todas as
consideraes fsicas, ou seja, independente dos detalhes de implementao, das linguagens
de programao, das plataformas de hardware, etc. O modelo conceptual ser de seguida
documentado em nove etapas:
1. Identificar o tipo de entidades;

2. Identificar o tipo de relacionamentos;
3. Identificar e associar atributos com entidades ou tipos de relacionamentos;
4. Determinar o domnio dos atributos;
5. Determinar chaves candidatas, primrias e alternadas;
6. Considerar o uso de conceitos de modelagem avanada;
7. Procurar por redundncia no modelo;
8. Validar o modelo conceptual com perguntas do utilizador;
9. Rever o modelo conceptual com o utilizador.
De seguida apresenta-se com algum detalhe o desenvolvimento de cada um destes

pontos descritos acima, assim como na Figura 1 est representado o esquema conceptual
atualizado relativo ao projeto.
Figura 1 - Esquema conceptual
3.1. Identificar as entidades do problema

O primeiro passo da construo do modelo conceptual passa por identificar as
entidades relevantes do problema, que sero os principais objetos em que o utilizador est
interessado. A classificao dos objetos do problema como entidades do modelo, ou no, deve
ser um processo cuidadoso e metdico. O facto de um objeto do problema ter uma importncia
considervel no implica que este seja classificado como entidade no modelo conceptual.
Inicialmente sero apresentadas as entidades importantes do problema e a justificao da sua
existncia. De seguida sero documentadas todas as entidades num dicionrio de dados com
uma descrio, um sinnimo e a justificao pela ocorrncia dessa mesma entidade.
3.1.1 Cliente
O cliente uma das entidades mais importantes no processo de venda, pois vai
adquirir os produtos que a BelaPadaria produz. O processo de venda torna-se mais rpido e
prtico se os dados do cliente forem adquiridos previamente, no entanto, o registo de cada
cliente no obrigatrio. Posto isto notvel a necessidade da criao da entidade clientes.
8
3.1.2 Funcionrio
Uma outra personagem importante no processo de venda e fabrico ser a entidade
funcionrio. Esta surge na venda como representante desta fbrica de produzir po, ainda que,
nem todos os funcionrios desta empresa estejam em contato direto com o pblico. Surge
ento a entidade funcionrios.
3.1.3 Pedido
A entidade Pedido servir para registar todos os produtos e as quantidades pedidas
por cada entidade Cliente. Como tal, o registo pormenorizado dos pedidos so cruciais no
nosso problema.
3.1.4 Produto
Os diferentes tipos de produtos devem ser caracterizados com detalhe de modo a
serem facilmente identificados. Surgem portanto a entidade produto. Existem vrios tipos de
pes e ainda alguns tipos de bolos, como baguetes, po bijou, po centeio, broa de milho, po
com chourio, bolas de Berlim, tarte de morango podero ser alguns dos exemplos dos
produtos presentes no sistema.
3.1.5 Dicionrio de dados das entidades

Nome da
Entidade
Descrio
Sinnimos
Esta entidade representa as

vrias pessoas que compram
produtos na BelaPadaria.
Consumidor
Clientes
Esta entidade representa os

produtos finais que so vendidos
pela BelaPadaria.
Artigo
Produtos
Entidade que representa a vrias

pessoas que trabalham na
BelaPadaria.
Empregado
Funcionrios
Pedidos
Esta entidade representa o

pedido que o cliente faz a
BelaPadaria.
Pedido
Ocorrncia
Cliente das entidades mais

importantes e principais pois so quem
efetuam compras na padaria.
Produto outra das entidades mais
relevantes do problema.
o produto que vendido ao cliente.
O Funcionrio pode ter vrios cargos e
so os funcionrios que fazem a
empresa e que a representam.
O pedido composto por um ou mais
produtos que o cliente pretende
comprar.
Tabela 1 - Dicionrio de dados das entidades
3.2. Identificar tipos de relacionamentos

Aps identificar as entidades necessrio identificar os seus relacionamentos. Em
primeiro lugar ser apresentado um diagrama ER do modelo para ser mais fcil perceber as
entidades e a forma como elas se relacionam entre si. A acompanhar o modelo ER ser
apresentado o Dicionrio de dados dos relacionamentos.
Figura 2 - Relacionamento entre Entidades
3.2.1 Dicionrio de dados dos relacionamentos
Nome Entidade
Multiplicidade
Relacionamento
Multiplicidade
Nome Entidade
Funcionrio
(1, 1)
Gere
(0, n)
Funcionrio
Funcionrio
(1, n)
Regista
(0, n)
Pedido
Funcionrio
(1, n)
confeciona
(0, n)
Produto
Pedido
(1, n)
feito pelo
(1, 1)
Cliente
Pedido
(1, n)
constitudo
(1, n)
Produto
Tabela 2 - Dicionrio de dados dos relacionamentos
10
3.3. Identificar e relacionar atributos com as

entidades
tipos
de
relacionamentos/
Determinar domnios de atributo

O passo seguinte da metodologia passa por identificar os atributos de cada entidade e
de cada relacionamento. Para tal identificao necessrio analisar os requisitos e perguntar
Qual a informao que preciso para guardar esta entidade ou este relacionamento?. Ser
tambm feita com esta fase a atribuio dos domnios dos atributos, ou seja, atribuir o intervalo
de valores que os atributos podem tomar.
Apresentar-se- ento de seguida o dicionrio de dados com os nomes das entidades,
os seus atributos, a descrio de cada atributo, o domnio de valores, se o atributo pode ser
nulo ou no e o tipo de atributo (simples, composto, derivado ou multi-valor).
3.3.1 Dicionrio de dados dos atributos das entidades

Entidade
Atributo
Descrio
Tipo de
dados e
tamanho
Nulo
Chaves
IdCliente
Cdigo que identifica

univocamente um cliente.
Int
No
Primria
Nome
Nome completo do cliente.
Varchar 75
Sim
NrCartaoCidadao
Nmero do carto de cidado

que identifica o cliente.
Numeric 8
Sim
NrContribuinte
Nmero de Identificao Fiscal.
Numeric 9
Sim
DataNascimento
Data de nascimento do cliente.
DATE
Sim
CdigoPostal
Cdigo postal da residncia do

cliente
Varchar 8
Sim
Rua
Nome da rua do cliente, onde

reside
Varchar 75
Sim
Concelho
Nome do concelho do cliente.
Varchar 75
Sim
Telemvel
Nmero de telemvel do cliente.
Numeric 9
Sim
E-mail
E-mail do cliente.
Varchar 75
Sim
idProduto
Nmero que identifica o produto.
Int
No
Clientes
Produtos
11
Primria
Funcionrios
nome
Designao do produto, o seu

tipo. (Broa de milho, baguete,
bijou)
Varchar 75
No
preo
Preo do produto.
Numeric 7, 2
No
stock
Stock do produto.
Int (10)
No
durao
Tempo que demora a um

produto estar pronto.
TIME
Sim
idFuncionario
Nmero que identifica o

funcionrio.
Numeric 8
No
Nome
Nome do funcionrio.
Varchar 75
No
Salrio
Salrio que o funcionrio recebe

por parte da empresa.
Numeric 8, 2
No
NIB
Nmero de identificao
bancria, para a qual recebe o
salrio.
Numeric 22
No
NrCartaoCidadao
Nmero do carto de cidado do

funcionario.
Numeric 8
No
NrContribuinte
Nmero de identificao fiscal do

funcionrio.
Numeric 9
No
DataNascimento
Data de nascimento do
funcionrio.
DATE
No
CdigoPostal
Cdigo Postal do funcionrio.
Numeric 8
No
Freguesia
Nome da freguesia do
funcionrio.
Varchar 75
No
NPorta
Nmero da porta do funcionrio.
Varchar 10
Sim
Rua
Nome da rua do funcionrio.
Varchar 75
Sim
Concelho
Nome do concelho do
funcionrio.
Varchar 75
No
Distrito
Nome do distrito do funcionrio.
Varchar 75
No
Telemvel
Nmero de telemvel do
funcionrio.
Numeric 9
No
Telefone
Nmero de telefone do
funcionrio.
Numeric 9
Sim
Facebook
Endereo de facebook do
funcionrio.
Varchar 75
Sim
E-mail
Endereo de e-mail do
funcionrio.
Varchar 75
Sim
12
Primria
Pedidos
horario
Nmero inteiro correspondente a

um horrio que determina o
nmero de horas que um
funcionrio trabalha
Nmero inteiro
No
id
Nmero que identifica o pedido

efetuado pelo cliente/recebido
pelo funcionrio.
Nmero inteiro
No
valor
Valor total dos produtos

constituintes do pedido (soma
dos preos)
DECIMAL 7, 2
No
dataHora
Data e hora a que o pedido foi

entregue e devidamente pago.
DATETIME
No
Primria
Tabela 3 - Dicionrio de dados dos atributos das entidades
3.3.2 Dicionrio de dados dos atributos das relaes

Relao
Atributo
Descrio
Tipo de dados
e tamanho
Nulo
Pedido
constitudo por
produto
quantidade
A quantidade de cada
produto que constitui o
produto
Numeric 8
No
quantidade
A quantidade de
produtos que foram
confecionados pelo
funcionrio
Numeric 8
No
dataConfe
A data de confeo de
um produto por um
funcionrio
DATETIME
Sim
Produto
confecionado
por funcionrio
Tabela 4 - Dicionrio de dados dos atributos dos relacionamentos
13
3.4. Determinar chaves candidatas, primrias

e alternadas
Nesta etapa necessrio determinar qual o conjunto das chaves candidatas do
conjunto de atributos de uma entidade. A partir dessas chaves candidatas escolhida a chave
primria e as restantes podero ser chaves alternadas. Uma chave alternada ento uma
chave que candidata, no foi eleita primria, mas sobre a qual se iro fazer vrias pesquisas.
importante eleger-se chaves alternadas se se verificar que se iro fazer vrias pesquisas
sobre esse atributo, pois leva criao um ndice ordenado por esse mesmo atributo
aumentando assim a eficincia dessas pesquisas. Comeamos ento por demostrar um
diagrama de relacionamento de entidades com as chaves primrias adicionadas.
Figura 3 - Diagrama ER com as chaves primrias adicionadas
Documentar-se- de seguida as escolhas e as justificaes das chaves para cada entidade:
Clientes:
Chaves candidatas: {idCliente, nr_cartao_cidadao, nr_contribuinte}
Chave primria: A chave primria escolhida ser o id pois, apesar de todos serem do
mesmo domnio (nmeros inteiros), o que tem menor ordem de grandeza.
Chaves Alternadas: nr_cartao_cidadao,nr_contribuinte
Pedidos:
Chaves candidatas: {idPedidos}
14
Chave primria: A escolha da chave primria recai na nica chave candidata, id.
Chaves Alternadas: Nenhuma.
Funcionrios:
Chaves candidatas: {idFuncionarios, nr_cartao_cidadao, nr_contribuinte}
Chave primria: A chave primria escolhida ser o id pois, apesar de todos serem do
mesmo domnio (nmeros inteiros), o que tem menor ordem de grandeza.
Chaves Alternadas: nr_cartao_cidadao, nr_contribuinte
Produtos:
Chaves candidatas: {idproduto, Nome}
Chave primria: A chave primria escolhida ser o id pois, comparando com o nome,
requer menor carga computacional pois o nome uma string e o id um inteiro.
Chaves Alternadas: Nenhuma.
3.5. Considerar o uso de modelao avanada

Nesta etapa da metodologia necessrio verificar se aplicvel o uso de conceitos de
modelao avanada tais como agregaes ou composies. No entanto, como este se trata
de um passo opcional da Modelao Conceptual, e dada a elevada importncia que possui
representar claramente as entidades e relacionamentos mais importantes, optamos por no
implementar esta generalizao e manter assim a simplicidade do diagrama ER.
3.6. Verificar que no existem redundncias

no modelo
Nesta etapa do projeto necessrio analisar o modelo conceptual em busca de
redundncia e elimin-la caso exista. Num primeiro passo devem ser examinados todos os
relacionamentos de multiplicidade um-para-um. Neste passo, o objetivo rever o modelo de
forma a identificar se existe alguma redundncia presente e no caso de existir, remov-la.
Observando o modelo elaborado, constata-se que no existem relacionamentos do tipo umpara-um, logo no existe a possibilidade de haver redundncia neste aspeto.
No segundo passo do processo devem ser removidos os relacionamentos

redundantes. Um relacionamento redundante quando possvel obter a mesma informao
custa de outros relacionamentos. relativamente fcil verificar a existncia de mltiplos
15
caminhos entre duas entidades do modelo, contudo isso no implica que existam
relacionamentos redundantes entre elas, pois tais relacionamentos podem representar
associaes distintas.
3.7. Validar
Modelo
com
perguntas
do
utilizador
Neste momento est definido um modelo conceptual que representa os requisitos
impostos pela BelaPadaria. Assim, justifica-se ento a verificao de todo o modelo de forma a
garantir que este consegue dar resposta a todas as interrogaes requeridas pelo utilizador. Se
o modelo no conseguir responder a alguma das interrogaes analisadas, ento significa que
houve algum erro na modelao, e podero ter de ser repetidos alguns passos da modelao
conceptual j realizados. Apresentar-se-o de seguida as perguntas e as suas respostas tendo
em conta as entidades e relacionamentos que sero usados para responder.
Quantos produtos foram fabricados num dia de uma determinada semana?

Para saber quantos produtos foram fabricados num dia de uma determinada semana,
apenas necessitamos da entidade Produto, a partir da qual conseguimos obter toda a
informao necessria para a obteno do resultado pretendido.
Qual o preo de determinado produto?

Para sabermos o preo de determinado produto, basta acedermos a entidade produto que
contem o atributo preo que nos diz exatamente qual o preo do produto em causa.
Qual o stock existente de determinado produto?

Para sabermos o stock existente, temos como atributo da entidade produto o stock que nos diz
exatamente o valor que temos em stock. Desta forma evitamos a quebra na venda por falta de
produto a ser comercializado.
Qual o nmero de pedidos efetuados entre duas datas?

Esta pergunta essencial para perceber o volume de vendas em determinadas pocas, para
sabermos quantos pedidos foram efetivamente efetuados entre duas datas basta acedermos a
entidade pedidos que possui o atributo data e da fazer a pesquisa pretendida.
Qual o nmero de pedidos que determinado cliente fez entre duas datas?
Esta pergunta importante, pois percebe-se desta forma, se o cliente est ou no satisfeito
com os nossos produtos, para sabermos quantos pedidos foram efetivamente efetuados entre
16
duas datas por um determinado cliente, temos que inicialmente saber quais os clientes que
efetuaram pedidos e depois basta somar o nmero de pedidos nas respetivas datas.
Que funcionrio registou determinado pedido?

Esta pergunta importante no sentido de, se houver algum problema com algum pedido de
algum cliente, sabe-se, a qual funcionrio nos devemos de dirigir para resolver a situao.
Desta forma para sabermos esta informao acedemos a entidade funcionrio que registou
determinado pedido e conseguimos toda a informao necessria para identificar o individuo.
Quanto tempo demora a fazer um certo produto?

Saber o tempo necessrio que ir demorar a confeo de determinado produto para informar o
cliente importante e ento para obtermos tal informao acedemos a entidade produto que
contem o atributo durao que nos informa diretamente quanto ao tempo que efetivamente
pretendemos saber.
Qual a quantidade de vendas de um certo produto?

necessrio saber quais so os produtos que se vendem mais, para que a padaria os
confecione ou compre em maiores quantidades; reduzindo desta forma a compra ou fabrico
dos produtos que so menos vendidos.
Quais foram os produtos confecionados por um determinado funcionrio cujo pedido foi
efetuado numa determinada data?
Acedemos a entidade pedido que contem o atributo data no qual fazemos uma pesquisa pelo
dia pedido, e daqui resultam todos os pedidos referentes ao dia em causa. De seguida para
cada um desses pedidos consultamos todos os produtos que o constituem e para cada um
desses produtos consultamos o funcionrio que o confecionou fazendo uma pesquisa pelo id
do funcionrio.
Quais foram os clientes que foram atendidos por determinado funcionrio?

Para determinar quais foram os clientes que foram atendidos por determinado funcionrio
acedemos a entidade pedido e dessa forma obtemos todos os pedidos que foram registados
pelo funcionrio em questo. De seguida para cada um desses pedidos conseguimos o cliente
que o efetuou.
Que funcionrio registou determinado pedido?

Para responder a esta pergunta necessrio cruzar a informao da entidade funcionrio e
entidade pedido.
17
3.8. Rever e validar o Modelo com o Utilizador

Para finalizar esta fase, o modelo conceptual desenhado deve ser revisto com o
utilizador. Este processo extremamente importante na medida em que o utilizador deve ser
capaz de reconhecer, assinando, que o modelo de dados concebido uma representao real
dos requisitos da empresa a ser modelada. Este passo tambm uma forma de avaliar o
trabalho feito face aos requisitos do utilizador. Foi avaliada toda a documentao associada ao
modelo de dados, ou seja, o dicionrio de dados de entidades, o dicionrio de dados de
relacionamentos, o dicionrio de dados de atributos e o diagrama ER.
Na reviso do dicionrio de entidades foi possvel identificar todas as entidades
importantes no modelo e constatar com o cliente que correspondem aos objetos considerados
importantes no problema e s necessidades da empresa. Na reviso do dicionrio de
relacionamentos foi justificada a forma como as entidades esto associadas e o utilizador
verificou que estes relacionamentos correspondem realidade do problema. J na reviso do
dicionrio de atributos o utilizador pode verificar mais concretamente a informao associada a
cada entidade e validar o domnio de cada atributo, constatando que estes correspondem aos
requisitos anteriormente apresentados. Por fim, na reviso do diagrama ER foi possvel obter
uma viso geral do modelo de dados e realizar a verificao de algumas das perguntas mais
frequentes no problema de modo a testar as capacidades do mesmo. O modelo de dados foi
aprovado pelo cliente como sendo uma soluo que d resposta a todas as necessidades da
empresa.
18
4. Modelo Lgico
Terminada a modelao conceptual, procedemos fase de modelao lgica. Esta
consiste na traduo do modelo conceptual anteriormente desenvolvido para um modelo lgico
capaz de representar os requisitos definidos, assim como a validao do mesmo. Aps a
concluso desta fase, deveremos obter um modelo lgico nico representativo dos requisitos
do sistema. Este modelo est apresentado na figura abaixo:
Figura 4 - Modelo Lgico
4.1. Derivao das relaes para o modelo

lgico
Neste primeiro passo, necessrio derivar as entidades, relacionamentos e atributos
considerados no modelo conceptual para as relaes do modelo lgico. Foi usada a DDL
19
(Database Definition Language), onde se descreve a composio de cada uma das relaes,
tendo por base as seguintes estruturas que se podem encontrar no modelo conceptual:
1 - Entidades Fortes
2- Relacionamentos muitos-para-muitos
3- Relacionamentos um-para-muitos Recursivos
4- Relacionamentos um-para-muitos
Para cada um dos pontos acima listados ser descrito como foram abordados no contexto do
problema de forma a derivar as relaes e os relacionamentos alcanados no modelo lgico.
1 - Entidades Fortes
Uma entidade forte uma entidade que no depende da existncia de outra entidade e
que pode por si s formar uma chave primria com os seus atributos. No modelo desenvolvido
todas as nossas entidades so fortes.
Clientes (idCliente, nrCartaoCIdadao, nome,

codPostal, rua, concelho, telemvel, email)
Chave Primria: idCliente
Funcionarios (idFuncionarios, horario, nib, salario, nome, nrContribuinte,

dataNascimento, nrCartaoCidadao, nrPorta,rua, freguesia, concelho, distrito, codPostal,
telemvel, telefone, facebook, email, Funcionario)
Chave Primria: idFuncionarios
Chave Estrangeira: Funcionario
Pedidos (idPedido, valor, dataHora)

Chave Primria: idPedido
Produtos (idProduto, nome, preo, duracao, stock)

Chave Primria: idProduto
nrContribuinte,
dataNascimento,
2- Relacionamentos muitos-para-muitos
Quando este tipo de relacionamentos acontece criada uma nova relao que conter
todos os atributos que fazem parte do relacionamento. A nova relao ter uma cpia das
chaves primrias das entidades que participam no relacionamento e funcionam como chaves
estrangeiras. Uma dessas chaves ou mesmo as duas formaro a chave primria da nova
relao ou ainda em combinaes com outros atributos da nova relao. Desta forma surgem
as seguintes relaes:
Funcionarios - Pedidos
Resulta:
FuncionariosPedidos (Funcionario, Pedido)
Chaves Estrangeiras: Funcionario correspondente a idFuncionario
20
Pedido correspondente a idPedido

Chave Primria: (Funcionario, Pedido)
Funcionarios Produtos
Resulta:
FuncionariosProdutos (Funcionario, Produto, quantidade)
Chaves Estrangeiras: Funcionario correspondente a idFuncionario
Produto correspondente a idProduto
Chaves Primrias: (Funcionario, Produto)
Pedidos Produtos
Resulta:
PedidosProdutos (Pedido, Produto, quantidade)
Chaves Estrangeiras: Pedido correspondente a idPedido
Produto correspondente a idProduto
Chaves Primrias: (Pedido, Produto)
3- Relacionamentos um-para-muitos Recursivos

Neste tipo de relacionamentos, a entidade de multiplicidade muitos fica com um novo
atributo (chave estrangeira) que a chave primria representante da outra entidade. Temos no
nosso modelo a seguinte:
Funcionarios (idFuncionarios, horrio, nib, salario, nome, nrContribuinte,

dataNascimento, nrCartaoCidadao, nrPorta, rua, freguesia, concelho, distrito,
codPostal, telemovel, telefone, facebook, email, Funcionario)
Chave Primria: idFuncionarios
Chave Estrangeira: Funcionario
4- Relacionamentos um-para-muitos
Neste tipo de relacionamentos, a entidade de multiplicidade muitos fica com um novo
atributo (chave estrangeira) que a chave primria representante da outra entidade. Temos no
nosso modelo a seguinte
Pedidos (idPedido,valor, dataHora, Cliente)

Chaves Primrias: (idPedido)
Chaves Estrangeiras: Cliente correspondente a idCliente
Clientes (idCliente, nrCartaoCidadao, nome, nrContribuinte, datNascimento, codPostal,

rua, concelho, telemvel, email)
Chaves Primrias: (idCliente)
21
4.2. Validao
das
relaes
atravs
da
normalizao
Esta fase do processo tem como objetivo decidir quais os atributos que pertencem em
conjunto numa relao. Sero validados os atributos presentes em cada relao de modo a
assegurar que estes so os necessrios para sustentar os requisitos de dados. As relaes
devem da mesma forma ser validadas para evitar redundncia e situaes de inconsistncia
aquando de inseres ou atualizaes. Devem ser identificadas as dependncias funcionais
entre atributos em cada relao e todas as chaves primrias. De notar que estas dependncias
funcionais identificam os relacionamentos do modelo de dados. O resultado da normalizao
um modelo lgico estruturalmente consistente e que possui mnima redundncia. No entanto,
s vezes discutido que um desenho de uma base de dados normalizada no oferece o
mximo de eficincia de processamento. A normalizao fora-nos a perceber completamente
cada atributo e o que representa na base de dados. O processo de normalizao ser
executado at terceira forma normal.

Para aplicar a 1FN numa tabela desnormalizada, necessrio identificar os atributos
ou grupos de atributos repetidos. Um atributo, ou grupo de atributos repetidos, aquele que
ocorre numa tabela vrias vezes para uma mesma chave primria.
Sendo que as regras da primeira forma normal j foram previamente aplicadas e que
todos os atributos j foram devidamente identificados, resta-nos apenas verificar que todos os
atributos presentes nas relaes se tratam de atributos atmicos.
Como o nosso modelo relacional no possui atributos multi-valor nem grupos repetidos,
conclumos que respeita a 1Forma Normal.

Para que a segunda forma normal seja verificada necessrio que o modelo de dados
se encontre j na primeira forma normal e que os atributos no-chave de relaes que
contenham chaves primrias compostas sejam funcionalmente dependentes da totalidade da
chave, ou seja, no podem existir atributos numa relao que sejam dependentes apenas de
uma parte da chave, pois caso isso se verificasse, o modelo iria sofrer de anomalias de
atualizao.
22
Neste caso como tambm j foram tomadas consideraes acerca das dependncias
funcionais nas relaes, tambm j no possvel encontrar no modelo casos em que a
segunda forma normal seja desrespeitada.
Assim como os atributos nessa tabela so dependentes da totalidade da chave, a
segunda forma normal j se verifica.

Para que uma relao se encontre na terceira forma normal, necessrio que se
encontre j na segunda forma normal e que para alm disso no existam nela atributos nochave-primria que sejam transitivamente dependentes da chave primria, ou seja, no pode
existir um atributo que seja ao mesmo tempo funcionalmente dependente da chave primria e
de um outro atributo. Assim, para que seja verificada a terceira forma normal, necessrio
eliminar as dependncias transitivas presentes nas relaes do modelo. Sendo assim,
conclumos que todas as relaes respeitam a 3 Forma Normal pois todos os atributos nochave dependem, inteira e exclusivamente, da totalidade da chave.
Aps a verificao de todas as relaes do nosso modelo relacional, conclumos que
este se encontra normalizado at 3Forma Normal.
4.3. Validao
das
relaes
atravs
das
transaes dos utilizadores

Finalizada a derivao do Modelo Lgico, necessrio assegurar que a partir deste
possvel obter resposta a todas as perguntas que um utilizador possa realizar. Assim,
similarmente verificao efetuada na Modelao Conceptual, foi testada se as transaes
requisitadas pelo utilizador so tambm suportadas pelo Modelo Lgico.
1 Transao: Inserir pedido, associar funcionrio ao pedido e adicionar produto ao

pedido
Nesta transao pretende-se demonstrar o caminho do registo de um pedido. Para tal

ser inserido um novo pedido aos pedidos existentes na nossa base de dados, com a insero
deste novo pedido ir ser necessrio definir o funcionrio, o cliente e a quantidade dos
produtos constituintes do pedido. Ser feita a insero na tabela FuncionariosPedidos o
Funcionario correspondente ao idPedido, assim como a insero na tabela PedidosProdutos o
23
produto e a respetiva quantidade. Sendo desta forma executada a transao de registo de um

pedido.
2 Transao: Atualizao do stock de um produto aquando da confeo de um

produto por um funcionrio
Nesta transao pretende-se que o valor do stock se mantenha consistente, para tal
sempre que um funcionrio confeciona uma quantidade de produtos o stock desse produto
necessita de ser atualizado. Ser feita a insero na tabela FuncionariosProdutos o funcionrio
responsvel pela confeo do produto, a quantidade e data de confeo. Desta forma ser feita
uma atualizao ao stock na tabela Produtos, mantendo assim a coerncia de dados.
3 Transao Substituir o funcionrio despedido na tabela FuncionariosPedidos e

eliminar o funcionrio despedido na tabela Funcionarios
Nesta transao atualizada a nossa lista de funcionarios, ser feita uma atualizao
na tabela FuncionarioPedidos onde ocorre a substituio do funcionrio despedido pelo novo
funcionrio. De seguida ser efetuada a eliminao do funcionrio despedido da tabela
Funcionarios.
4.4. Anlise das restries de integridade

O objetivo agora garantir que o modelo lgico que foi construdo representa de forma
correta os dados pretendidos para a empresa BelaPadaria. Para que o modelo lgico esteja de
acordo com o pretendido preciso garantir que todas as restries de integridade so
respeitadas e portanto o que est feito o pretendido para a base de dados da BelaPadaria.
Se os pontos apresentados a seguir forem respeitados garante-se que a base de
dados contem dados credveis e que a sua manipulao consistente e sem falhas nas regras
de negcio.
1 - Necessidade de valores no-nulos:
24
As chaves primrias so valores que no podem ser nulos mas podem existir outros que por
regras de negcio tambm se enquadram neste ponto. Todos os atributos que podem ter esta
caracterstica podem ser visualizados no dicionrio de dados lgico.
2 - Restries de domnio do atributo:
Todos os atributos tem a si associado um domnio que define a gama ou tipo de valores que
cada atributo pode ter. Desta forma tenta-se dar algum significado a cada atributo guardado de
forma a diminuir possveis erros futuros do utilizador. O domnio dos atributos foi apurada no
desenvolvimento j efetuado e pode ser visualizado no dicionrio de dados do modelo
conceptual.
3 Multiplicidade:
A multiplicidade uma restrio que diz respeito ao relacionamento entre entidades. esta
regra que identifica a cardinalidade que ocorre entre duas relaes, ou seja, identifica a forma
como os dados se relacionam. A multiplicidade est presente desde logo no modelo conceptual
e consequentemente ir passar para o modelo lgico. O modelo lgico gerado est dependente
da multiplicidade presente no modelo conceptual e portanto para cada multiplicidade diferente
gerado uma soluo diferente.
4 - Integridade da entidade:
Esta integridade garantida pelo uso de uma chave primria que seja nica e no nula. Desta
forma garante-se que cada tuplo identificado univocamente por uma chave na relao. A
forma como a chave primria formada depende do caso em estudo mas desde que se
cumpra as duas regras apresentada esta integridade ser cumprida. Esta restrio foi
considerada na identificao das chaves primrias e explicita no dicionrio de dados.
5 - Integridade referencial:
Esta regra de integridade diz respeito a forma como as chaves estrangeiras so utilizadas.
Independentemente da sua utilizao obrigatrio garantir que os relacionamentos entre as
relaes sejam preservados e o modelo relacional seja respeitado, ou seja, esta restrio
pretende garantir que o valor de uma chave estrangeira de uma relao filho seja o mesmo e
exista na chave primria da relao pai associada. Sempre que uma chave estrangeira sofra
alteraes devido a remoes e modificaes esta integridade deve ser verificada. O dicionrio
de dados explicita que as chaves estrangeiras so eleitas chaves primrias de outras tabelas.
Esta restrio supervisiona a consistncia da base de dados, uma vez que uma alterao
numa chave primria deve ser refletida nas chaves estrangeiras a esta associada.
25
Esta restrio ajuda na consistncia da base de dados e deve portanto ser verificada
sempre que uma relao "pai" sofra qualquer tipo de alterao ou remoo.
Inserir um registo na relao filho Apenas se verifica se a chave estrangeira na

relao filho tm alguma correspondncia com o valor da chave primria na relao
pai.
Remover um registo da relao filho Uma remoo na relao filho no afeta a

integridade em qualquer aspeto.
Atualizao de um registo na relao filho O procedimento totalmente igual ao

de inserir um registo na relao filho.
Inserir um registo na relao pai Uma insero na relao pai no interfere com a
integridade referencial. Contudo de modo manter a informao atualizada e consistente
necessrio proceder atualizao nas respetivas relaes filho.
Remover registo na relao pai No caso da remoo de um registo na relao pai a

integridade referencial pode ser posta em causa, na medida em que pode existir um
registo numa relao filho sem uma entidade pai. Neste sentido, foi decidido que
iriamos utilizar a funcionalidade NO ACTION que impede que a remoo de um registo
na relao pai se existir algum registo filho. Para alm disso, foi tambm utilizada a
funo CASCADE de modo a atualizar as chaves estrangeiras associadas a esta
chave primria.
Atualizar a chave primria num registo pai Da mesma forma que a situao
anterior, as atualizaes da chave primria num registo pai devem ser refletidas na
relao filho. Por isso foram novamente consideradas as estratgias de NO ACTION e
CASCADE.
6 - Restries gerais:
Por fim, necessrio ver representadas no modelo as restries que dizem respeito a
regras de negcio. Todas as restries deste tipo sero apresentadas abaixo, agrupadas por
relao. Como todas as restries acima enunciadas estas tambm tm de ser refletidas no
modelo de forma a que o modelo represente a organizao da BelaPadaria de forma correta.
Clientes
O nmero do BI, NIF, email so nicos
26
Esta restrio est definida no script de criao das tabelas, passaremos a mostrar na
imagem a baixo um exemplo:
Figura 5 - Excerto da script criao da tabela Clientes
Funcionrios
Para se registar, um funcionrio dever ter idade igual ou superior a 18 anos e inferior
a 65 anos, o seu salrio dever ser superior a 0
O nmero do BI, NIF, email, nib, facebook so nicos
Figura 6 - Excerto da script criao da tabela Funcionarios
27
Produtos
Os preos dos produtos devero ser superior a zero euros
Figura 7 Excerto da Criao da script criao da tabela Produtos
Pedidos
O valor do pedido dever ter um valor superior a zero
Figura 8 - Excerto da script de criao da tabela Pedidos
4.5. Reviso
do
modelo
lgico
com
utilizador
A reviso do modelo lgico junto do utilizador tem como principal objetivo validar o
desenho lgico de acordo com as especificaes do cliente.
Primeiramente foi apresentado a evoluo da arquitetura da sua fase inicial,
conceptual, para a fase lgica. Recorrendo ao dicionrio lgico, foi possvel caracterizar toda a
estrutura a nvel da sua robustez, de garantias de consistncia de dados, e identificar de que
forma a estrutura vai de encontro com a realidade pretendida pelos requisitos do cliente. Aqui
foi tomado especial foco em relao a todas restries que o dicionrio lgico definia para cada
uma das relaes da estrutura.
28
Numa segunda fase, foi demonstrado atravs do mapa de transaes, que as

operaes crticas pretendidas podem ser facilmente satisfeitas, com segurana e segundo
todos os requisitos explicitados j numa fase anterior. Ainda com recurso ao mapa de
transaes, ficaram explcitas as reas da arquitetura mais atacadas com as transaes
pretendidas. O trabalho desenvolvido nesta fase visou satisfazer todas as necessidades do
cliente, sendo que, este no expressou qualquer necessidade de retificaes no modelo ou de
incluso de novos elementos.
4.6. Anlise do crescimento futuro

O objetivo deste tpico apresentar uma estimativa do crescimento da base de dados
com base em dados que a organizao da BelaPadaria disponibilizou. O clculo ir ser feito
tendo em conta o motor da base de dados escolhido para implementar o projeto, o sql server
2014. Inicialmente ser calculado o tamanho inicial que a base de dados ter de ter para a
BelaPadaria comear a funcionar e s posteriormente, prever o futuro crescimento.
Tamanho inicial da base de dados:

Tendo em conta os requisitos do sistema previamente analisados temos que inicialmente a
base de dados ter:
Cerca de 8 funcionrios
Cerca de 22 produtos
Cerca de 100 clientes
Cerca de 30 pedidos
Para se poder continuar a analise necessrio saber-se o tamanho que o sql server
2014 utiliza para cada tipo de dados. De seguida, apresenta-se um quadro resumo para os
tipos de dados utilizados no projeto e o seu respetivo tamanho.
Tipos de dados
Tamanho
Integer
4 bytes
Varchar(N)
2 + N bytes
DATE
3 bytes
DATETIME
8 bytes
29
DECIMAL (N, M)
N + M < 10 => 5 bytes

N + M < 20 => 9 bytes
N + M < 29 => 13 bytes
N + M < 39 => 17 bytes
TIME
3 bytes
Tabela 5 - Tipos de dados e tamanhos em Sql Server
Como no tamanho inicial da base de dados temos

8 funcionrios, basta multiplicar 8*734= 5872
bytes.
Tabela 6 - Tamanho inicial para a tabela Funcionarios
Como no tamanho inicial da base de dados temos 100

clientes, basta multiplicar 100*429= 4290 bytes.
Tabela 7 - Tamanho inicial para a tabela Clientes

30

produtos, basta multiplicar 22*129= 2838 bytes.
Tabela 8 - Tamanho inicial para a tabela Produtos

pedidos, basta multiplicar 30*17= 510 bytes.
Tabela 9 - Tamanho inicial para a tabela Pedidos

26 entradas na tabela FuncionariosProduto, basta
multiplicar 15*26= 390 bytes.
Tabela 10 - Tamanho inicial para a tabela FuncionariosProdutos

entradas
na
tabela
FuncionariosPedidos,
basta
multiplicar 8*30= 240 bytes.
Tabela 11 - Tamanho inicial para a tabela FuncionariosPedidos

29 entradas na tabela PedidosProdutos, basta
multiplicar 13*29= 377 bytes
31
Tabela 12 - Tamanho inicial para a tabela PedidosProdutos
O tamanho inicial da base de dados ser aproximadamente 41755 bytes (40,77Kbytes)

para que a BelaPadaria posso comear a funcionar.
Feito este passo, agora importante calcular o crescimento futuro da base de dados.
Utilizando os requisitos do sistema previamente levantados:
Um crescimento mensal de 20 clientes.
Fazem-se 200 vendas dirias.
Contrata-se em mdia 2 funcionrios novos por ano
Adicionam-se 1 nova distribuidora por ano
Adicionam-se, em mdia, 5 produtos por ms
Os pedidos aumentam cerca de 5% por ms
No final do primeiro ano o crescimento da BelaPadaria ser aproximadamente de

0.2653 Megabytes (278237 bytes) de dados.
32
5. Modelo Fsico
Nesta etapa efetuada a traduo do modelo lgico desenvolvido anteriormente para
um modelo fsico a ser implementado num SGBD. Esta etapa tambm desenvolvida no
sentido de otimizar o modo como os dados so guardados e acedidos. Existem diversas
estruturas de armazenamento dados. Ao passo que algumas delas so extremamente
eficientes na tarefa de guardar dados, umas so mais eficientes no modo como os dados so
acedidos. A escolha das estruturas de armazenamento naturalmente condicionada pelo
SGBD, j que estamos dependentes da disponibilizao ou no de estruturas alternativas de
armazenamento. O modelo de dado fsico deve ser totalmente dirigido para a natureza dos
dados e aquilo que se pretende realizar com eles.
Assim, so seguidamente descritas as relaes base, organizao de ficheiros e
ndices usados para alcanar um uso eficiente dos dados, e todas as restries de integridade
e medidas de segurana.
5.1. Traduo do modelo lgico para o SGBD

escolhido
Neste passo foi decidido como representar as relaes base identificadas no modelo
lgico, de modo a que as relaes e as suas restries possam ser suportadas pelo SGBD
escolhido. Para tal ser possvel os trs passos seguintes tero de ser corretamente efetuados:
desenhar as relaes base, desenhar as representaes dos dados derivados e desenhar as
restries gerais (de negcio), que descreveremos nos pontos seguintes.
5.1.1 Desenho das relaes base

Inicialmente preciso colocar disposio toda a informao sobre as relaes
apresentadas no modelo lgico de dados. Informao que diga respeito a domnios, valores por
defeito, valores nulos e todo o tipo de restries devem ser apresentados nesta fase. Para
33
cada relacionamento, e de forma muito parecido com o que foi feito para o modelo lgico, ser
apresentada a informao necessria mas agora tendo em considerao o SGBD escolhido.
Relao Pedidos
Domnio ID:
Inteiro
Domnio Valor:
Decimal
Domnio DataHora
DateTime
Domnio Cliente
Inteiro
Pedidos(
idPedido
ID
NOT NULL,
valor
Valor
NOT NULL,
dataHora
DataHora
NOT NULL,
Cliente
Cliente
NOT NULL
PRIMARY KEY (idPedido)

FOREIGN KEY (Cliente) REFERENCES (idCliente) ON UPDATE CASCADE ON DELETE NO
ACTION);
Relao Clientes:
Domnio ID
Inteiro
Domnio NrCartoCidado
String de tamanho fixo, tamanho 8
Domnio Nome
String de tamanho varivel, tamanho 75
Domnio NrContribuinte
Domnio DataNascimento
Data
Domnio CodPostal
Domnio Rua
Domnio Concelho
Domnio Telemvel
Domnio Email
Clientes(
idCliente
ID
NOT NULL,
nrCartaoCidadao
NrCartoCidado
NULL,
nome
Nome
NULL,
nrContribuinte
NrContrinuinte
NULL,
dataNascimento
DataNascimento
NULL,
codPostal
CodPostal
NULL,
rua
Rua
NULL,
34
concelho
Concelho
NULL,
telemovel
Telemvel
NULL,
email
Email
NULL,
PRIMARY KEY (idCliente)

);
Relao Funcionrios
Domnio ID
Inteiro
Domnio Horrio
Inteiro
Domnio NIB
Nmero de vrgula fixa, tamanho 22
Domnio Salrio
Decimal positivo com 2 casas decimais
Domnio Nome
Domnio nrContribuinte
Dominio DataNascimento
Data
Domnio NrCartoCidado
Inteiro, tamanho 8
Domnio NrPorta
Domnio Rua
Domnio Freguesia
Domnio Concelho
Domnio Distrito
Domnio CodPostal
Domnio Telemvel
Inteiro de tamanho fixo, tamanho 9
Domnio Telefone
Inteiro de tamanho fixo, tamanho 9
Domnio Facebook
Domnio Email
Domnio Funcionrio
Inteiro
Funcionrios(
idFuncionario
ID
NOT NULL,
horario
Horrio
NOT NULL,
nib
NIB
NOT NULL,
salario
Salrio
NOT NULL,
nome
Nome
NOT NULL,
nrContribuinte
NrContribuinte
NOT NULL,
dataNascimento
DataNascimento
NOT NULL,
nrCartaoCidadao
NrCartoCidado
NOT NULL,
nrPorta
NrPorta
NULL,
rua
Rua
NULL,
35
freguesia
Freguesia
NOT NULL,
concelho
Concelho
NOT NULL,
distrito
Distrito
NOT NULL,
codPostal
CodPostal
NOT NULL,
telemovel
Telemvel
NOT NULL,
telefone
Telefone
NULL,
facebook
Facebook
NULL,
email
Email
NULL,
Funcionario
Funcionrio
NULL,
PRIMARY KEY (idFuncionario),

FOREIGN KEY (Funcionario) REFERENCES (idFuncionario) ON UPDATE CASCADE ON
DELETE SET NULL);
Relao Produtos:
Domnio ID
Inteiro
Domnio Nome
Domnio Preo
Decimal positivo com 2 casas decimais
Domnio Durao
TEMPO
Domnio Stock
Inteiro
Produto(
idProduto
ID
NOT NULL,
nome
Nome
NOT NULL,
preco
Preo
NOT NULL,
duracao
Durao
NULL,
stock
Stock
NOT NULL,
Funcionario
FuncionrioID
NOT NULL,
Pedido
PedidoID
NOT NULL,
PRIMARY KEY (idProduto)

);
Relao FuncionriosPedidos:
Domnio FuncionrioID
Inteiro
Domnio PedidoID
Inteiro
FuncionriosPedidos (
PRIMARY KEY (Funcionario, Pedido),

36

DELETE CASCADE,
FOREIGN KEY (Pedido) REFERENCES (idPedido) ON UPDATE CASCADE ON DELETE
CASCADE);
Relao FuncionriosProdutos
Domnio FuncionrioID
Inteiro
Domnio ProdutoID
Inteiro
Domnio Quantidade
Inteiro
Domnio dataConfe
Data
FuncionriosProdutos (
Funcionario
FuncionrioID
NOT NULL,
Produto
ProdutoID
NOT NULL,
quantidade
Quantidade
NOT NULL,
dataConfe
Data Confeo
NULL
PRIMARY KEY (Funcionario, Produto),

DELETE CASCADE,
FOREIGN KEY (Produto) REFERENCES (idProduto) ON UPDATE CASCADE ON DELETE
CASCADE);
Relao PedidosProdutos:
Domnio PedidoID
Inteiro
Domnio ProdutoID
Inteiro
Domnio Quantidade
Inteiro
PedidosProdutos(
Pedido
PedidoID
NOT NULL,
Produto
ProdutoID
NOT NULL,
quantidade
Quantidade
NOT NULL,
PRIMARY KEY (Pedido, Produto),

FOREIGN KEY (Pedido) REFERENCES (idPedido) ON UPDATE CASCADE ON DELETE NO
ACTION,
FOREIGN KEY (Produto) REFERENCES (idProduto) ON UPDATE CASCADE ON DELETE
CASCADE);
37
5.1.2 Desenho das representaes dos dados derivados

Nesta seco discutida a utilizao dos atributos derivados. Estes so atributos cujo
valor pode ser calculado atravs de outros atributos.
Um exemplo de um atributo cujo valor poderia ser derivado seria o "Valor" de um
determinado Pedido. Este valor poderia ser calculado atravs dos preos e da quantidade de
cada produto pertencente a esse Pedido.
Contudo, este clculo teria de ser efetuado cada vez que se pretende efetuar a consulta do
valor desse dado atributo, sendo que esta operao requer um custo mais elevado quantos
mais produtos de um dado pedido estiverem associados. Assim, a opo tomada foi
acrescentar um atributo na entidade Pedido denominado "Valor" que ser atualizado sempre
que se associar um novo produto a um dado pedido. Desta forma, dado que o custo de
armazenamento deste atributo no particularmente significativo, possvel aceder
diretamente ao seu valor aumentando a performance de execuo.
Foi criado um gatilho para que sempre que fosse registado um pedido o valor do
pedido fosse a multiplicao do preo do produto pela quantidade, que demonstramos na
imagem abaixo.
Figura 9 - Script da criao do gatilho "AtualizaValor"
5.1.3 Desenho das restries gerais

Cada uma das restries gerais tm de ser implementadas no SGBD e o pretendido
agora exatamente isso. Para cada uma das restries de negcio ser apresentada uma
forma de a implementar tendo em considerao o motor escolhido. As solues encontradas
38
podem ser simplesmente implementadas com SQL standard ou utilizando mecanismos

especficos do SGBD como por exemplo, um trigger. A escolha da soluo vai depender muito
das capacidades do SGBD e caso alguma das restries no possam ser implementado por
ela, a soluo ser implementada pela aplicao. De seguida, cada uma das restries ir ser
apresentada e a sua respetiva soluo.
Nesta fase so definidas as restries gerais (ou regras de negcio) que servem para
garantir a coerncia no "mundo real" dos dados armazenados. Por exemplo, no faz sentido
existir uma tarefa cuja data de incio seja superior data em que foi finalizada. Assim,
necessrio impor regras que impeam a ocorrncia destes casos.
Relao Funcionrio
- A idade de um funcionrio deve ser igual ou superior a 18 anos e inferior a 65
Figura 10 - Criao de um gatilho que permite verificar o limite de idades
- O salrio de um funcionrio tem de ser maior que 0 unidades monetrias.

Para esta restrio ser garantida, foi implementada na script de criao das tabelas o
mecanismo CHECK (salario>0), como pode ser verificado na Figura 9.
Relao produto
-O preo de um certo produto dever ser igual ou superior a 0,0

-O stock existente desse produto dever ser superior ou igual a zero
39
Para estas restries serem respeitadas implementaram-se na script de criao das tabelas os
mecanismos CHECK (preco > 0) e CHECK (stock >= 0), como pode ser observado na Figura 7.
Relao Pedido
- O valor do pedido ter de ser maio que 0 .

Para estas restries serem respeitadas implementaram-se na script de criao das tabelas os
mecanismos CHECK (valor > 0)
5.2. Organizao dos ficheiros e ndices

5.2.1 Anlise de transaes
De forma a aumentar a performance da base de dados, foi necessria uma anlise das
transaes que ocorrem entre as relaes. A partir desta anlise, foi possvel perceber a sua
funcionalidade e identificar as mais importantes. Como foi referido anteriormente, na anlise de
requisitos, foi elaborada uma lista com algumas das principais queries. Atravs da anlise
dessa lista, conclumos que a maior parte das delas apenas implicam operaes de leitura. No
entanto, tambm existem operaes frequentes que implicam a insero/atualizao de valores
nas relaes. De qualquer das maneiras, optamos por criar uma script que identifica o tipo de
operaes que cada querie implica.
40
1 Transao - Inserir pedido, associar funcionrio ao pedido e adicionar produto ao

pedido
Figura 11 Transao 1 Criao do procedimento registarPedido
2 Transao: Atualizao do stock de um produto aquando da confeo de um

produto por um funcionrio
Figura 12 Criao do procedimento atualizarStockFromFunc
41
3 Transao Substituir o funcionrio despedido na tabela FuncionariosPedidos e

eliminar o funcionrio despedido na tabela Funcionarios
Figura 13 Criao do procedimento substiuFun
5.2.2 Escolha da organizao dos ficheiros

A base de dados em armazenamento secundrio organizada num ou mais ficheiros,
em que cada ficheiro contm vrios registos e cada registo composto por vrios campos. Por
norma, a cada registo est associado uma entidade e um campo de um atributo.
Guardar e aceder a dados de uma forma eficiente, um dos principais objetivos, no

desenho do esquema fsico de uma base de dados.
5.2.3 Escolha dos ndices

Um ndice uma estrutura de dados que permite ao SGBD localizar registos num
ficheiro mais rapidamente e, consequentemente, melhorar o tempo de resposta a queries do
utilizador. Todas as tabelas InnoDB tm um indice especial chamado indice "clustered"
(agrupado) onde a informao sobre os registos guardado. Normalmente, este indice
sinnimo da chave primria da tabela.
Todos os ndices InnoDB so B+Tree, onde os registos dos ndices so guardados
nas pginas-folha da rvore. O tamanho default de uma pgina 16KB. Quando novos registos
42
so inseridos, o InnoDB tenta deixar 1/16 da pgina livre para futuras inseres e updates nos
registos do ndice. Se os registos do ndice so inseridos de forma ordenada, as pginas
resultantes estaro praticamente preenchidas. Caso as inseres sejam feitas de forma
aleatrio, as pginas estaro entre metade e praticamente preenchidas. Se o fator de
preenchimento da pgina de um ndice baixar para menos de metade, o InnoDB tenta contrair
a rvore para libertar a pgina. Como foi referido, o InnoDB utiliza a chave primria de cada
tabela como ndice. Sendo assim, vamos apresentar alguns ndices:
Figura 14 - Criao de ndices
5.2.4 Estimativa de espao em disco necessrio

Como j foi referido anteriormente, utilizaremos o motor de armazenamento InnoDB do
MySQL. Visto isto, precisamos de saber, o espao necessrio para cada tipo de domnio
utilizado na base de dados. O InnoDB utiliza o COMPACT Row Format por defeito, e os
tamanhos do domnio so os seguintes:
Integer
4 bytes
Date
3 bytes
Varchar(N)
2+N bytes
Decimal (7,2)
5 bytes
Decimal (8,2)
9 bytes
Aps alguns clculos, conclumos que o espao necessrio para cada registo nas tabelas so
os seguintes:
Funcionarios
614
FuncionariosPedidos
Pedidos
17
Produtos
63
43
PedidosProdutos
13
FuncionariosProdutos
15
Clientes
337
Agora, de acordo com a informao da nossa base de dados o espao necessrio para cada
registo numa tabela a multiplicar pelo nmero de registos totais:
Funcionario
8*614 = 4912
FuncionariosPedidos
30*8 = 240
Pedidos
30*17 = 510
Produtos
22*63 = 1386
PedidosProdutos
13*29 = 377
FuncionariosProdutos
26*15 = 390
Clientes
100*337 = 33700
Somando todos os valores de cada tabela, estima-se que o tamanho inicial necessrio para
a base de dados ronde 41755 bytes (40,77Kbytes).
5.3. Desenho das vistas de utilizadores

Uma das questes importantes no desenvolvimento de um Sistema de Gesto de Base de
Dados a restrio das vistas de cada utilizador. A nossa implementao tem em conta que
existiro N tipos de utilizadores:
Administrador Tem acesso a toda a Base de Dados e pode executar todas as aes
que entender.
Chefe de padaria Tem acesso a toda a informao exceto os dados pessoais dos
clientes.
Funcionrio Tem os mesmos privilgios do que o chefe de seco, no entanto, com a

exceo de no conhecer os fornecedores.
Cliente Pode consultar os produtos que esto expostos, ver as compras que lhe
dizem respeito e os seus dados pessoais.
Em baixo apresentamos, para as vrias vistas possveis, o cdigo SQL respetivo
44
Figura 15 - Criao de uma Vista com o preario, visivel para os clientes
Figura 16 - Criao de uma vista coma informao dos horarios dos funcionrios
Figura 17 - Criao de uma vista contendo a informao dos clientes
Figura 18 - Criao de uma vista contendo a informao da relao cliente compra
5.4. Mecanismos de segurana

Nesta fase temos o objetivo de mostrar os mecanismos de segurana especificados
pelos utilizadores durante a definio dos requisitos.
Na anlise de requisitos definimos a existncia de trs tipos de utilizadores:
Funcionario,
Administradores e Clientes estes com a mesma vista mas com permisses
diferentes.
45
Funcionrios
Tem permisses de consulta e insero para todas as tabelas, mas este utilizador no
pode remover ou alterar nenhuma entrada de qualquer tabela.
Permisses para Funcionario:

- Necessrias para consulta
GRANT SELECT ON Pedidos TO Funcionario
GRANT SELECT ON Produtos TO Funcionario
GRANT SELECT ON Clientes TO Funcionario
GRANT SELECT ON Funcionarios TO Funcionario
- Necessrias para insero

GRANT INSERT ON Pedidos TO Funcionario
GRANT INSERT ON PedidosProdutos TO Funcionario
GRANT INSERT ON Clientes TO Funcionario
- Necessrias para no permitir alteraes

DENY UPDATE ON Produtos TO Funcionario
DENY UPDATE ON Clientes TO Funcionario
DENY UPDATE ON Funcionarios TO Funcionario
-Necessrias para no permitir remoes

DENY DELETE ON Clientes TO Funcionario
DENY DELETE ON Produtos TO Funcionario
DENY DELETE ON Funcionarios TO Funcionario
Administrador
Este tipo de utilizador deve ter permisses para realizar todas as tarefas sobre a base
de dados.
Permisses para Administrador

- Necessrias para poder realizar qualquer comando
GRANT ALL ON Funcionarios TO Administrador
GRANT ALL ON FuncionariosPedidos TO Administrador
GRANT ALL ON Pedidos TO Administrador
GRANT ALL ON PedidosProdutos TO Administrador
GRANT ALL ON Produtos TO Administrador
46
GRANT ALL ON Clientes TO Administrador

GRANT ALL ON FuncionariosProdutos TO Administrador
5.5. Considerao
de
introduo
de
redundncia controlada
A introduo de redundncia controlada apenas deve ser considerada quando se
prev que a Base de Dados criada no cumprir os requisitos de performance pretendidos,
dado que esta contribui para o surgimento de dados inconsistentes. Quando se pretende evitar
o processamento simultneo de vrias relaes, manter um qualquer sistema de arquivo ou
manter as relaes a um nvel (simples) que permita satisfazer as queries dos seus
utilizadores, desnormalizar o sistema em causa pode ser uma opo vivel. Apesar de a
desnormalizao contribuir positivamente para o desempenho das operaes de pesquisa,
acontece o contrrio relativamente s operaes de atualizao. Deste modo, poder fazer
sentido considerar a realizao deste processo para relaes cuja frequncia de atualizaes
seja pequena e bastante menor do que a frequncia de pesquisas efetuadas. Neste sistema
optou-se por no introduzir nenhum tipo de redundncia.
5.6. Monitorizar e afinar o sistema operativo

Um dos principais objetivos de uma base de dados guardar e aceder informao
de uma forma eficiente. H portanto, uma srie de fatores a ter em conta, nomeadamente, o
espao de armazenamento, o tempo de resposta do sistema ou o nmero de transaes que
se consegue processar num certo intervalo de tempo. Ao fazer com que uma Base de Dados
seja eficiente, necessrio conjugar todos estes fatores de tal modo que se atinja o melhor
equilbrio possvel entre os mesmos, ainda que tal implique priorizar uns em detrimento dos
outros. Desta forma, afinar um sistema operativo, uma atividade que nunca se completa.
Existe, ao longo da vida do sistema, a necessidade de monitorizar o seu desempenho, de
forma a explicar as mudanas no ambiente, e as necessidades dos utilizadores. No entanto,
uma alterao numa rea de um sistema para melhorar o sistema pode piorar o desempenho
noutra rea.
47
6. Ferramentas utilizadas
Para a elaborao deste documento foram utilizadas vrias ferramentas:
- Microsoft Word 2010: Elaborao deste documento.

- brModelo: Desenho do diagrama ER e do modelo conceptual.
- MySQL Workbench: Desenvolvimento do modelo lgico e fsico.
- Visual Paradigm 12.2: Desenho de mapa transacional.
- Microsoft SQL Server - Sistema de gesto de base de dados relacional
48
7. Concluses e Trabalho Futuro

O desenvolvimento de uma base de dados um processo complicado e demorado e
portanto, sendo feito de forma incorreta pode provocar elevados custos a uma organizao. Na
tentativa de diminuir possveis erros, deve ser seguida uma metodologia de forma a
sistematizar todo o processo de desenvolvimento.
Apesar dos vrios pontos positivos da utilizao de uma metodologia, o processo de
modelao torna-se bastante intensivo e demorado, podendo ento, ser desnecessrio para
casos simples. J para problemas complexos e com vrios utilizadores, a sua utilizao
fundamental para que se possa assegurar que o sistema desenvolvido o pedido pela
organizao.
A metodologia sugerida pelo livro Database Systems foi seguida risca na tentativa de
que o resultado satisfizesse com sucesso as necessidades da BelaPadaria. Durante a primeira
etapa de desenvolvimento, os futuros utilizadores da base de dados da BelaPadaria foram
consultados para que cada passo fosse validado e portanto considerado de acordo com os
requisitos.
De seguida implementamos o modelo lgico e o esquema fsico da base de dados e
um conjunto de testes, que serviu como ponto de partida para iniciar o funcionamento do
sistema. Futuramente tambm se pretende acompanhar a utilizao da base de dados por
parte da BelaPadaria, onde se poder intervir sempre que necessrio, fazendo a manuteno
do sistema.
No entanto, qualquer Base de Dados necessita de manuteno regular, de modo a
garantir que funcione bem e sem anomalias ao longo do tempo, caso isso no seja satisfeito,
ser diminuda lentamente a sua performance, deixando de ser funcional e, tornando-se
portanto, intil.
Por fim, achamos desta forma que conseguimos cumprir os objetivos definidos no incio
do projeto.
49
Bibliografia
Thomas M. Connolly, Carolyn E. Begg - Database Systems: A Practical Approach to Design,
Implementation and Management - 4th Edition.
50
Lista de Siglas e Acrnimos

BD
Base de Dados
ER
Entidade-Relacionamento
SGBD Sistema de Gesto de Base de Dados
51
Anexos
52
I.
Anexo 1 Script completo da criao do
esquema
-- MySQL Workbench Forward Engineering
SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;

SET
@OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,
FOREIGN_KEY_CHECKS=0;
SET
@OLD_SQL_MODE=@@SQL_MODE,
SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';
-- ------------------------------------------------------ Schema belapadaria

-- ----------------------------------------------------drop Schema if exists belapadaria;
-- ------------------------------------------------------ Schema belapadaria
-- ----------------------------------------------------CREATE SCHEMA IF NOT EXISTS `belapadaria` DEFAULT CHARACTER SET utf8 ;
USE `belapadaria` ;
-- ------------------------------------------------------ Table `belapadaria`.`Funcionarios`

-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `belapadaria`.`Funcionarios` (
ìdFuncionario` INT NOT NULL AUTO_INCREMENT,
`horario` INT NOT NULL,
`nib` DECIMAL(22) NOT NULL UNIQUE,
`salario` DECIMAL(8,2) NOT NULL CHECK (salario>0),
`nome` VARCHAR(75) NOT NULL,
`nrContribuinte` INT(9) NOT NULL UNIQUE,
`dataNascimento` DATE NOT NULL,
`nrCartaoCidadao` INT(8) NOT NULL UNIQUE,
`nrPorta` VARCHAR(10) NULL,
53
`rua` VARCHAR(75) NULL,

`freguesia` VARCHAR(75) NOT NULL,
`concelho` VARCHAR(75) NOT NULL,
`distrito` VARCHAR(75) NOT NULL,
`codPostal` VARCHAR(8) NOT NULL,
`telemovel` INT(9) NOT NULL,
`telefone` INT(9) NULL,
`facebook` VARCHAR(75) NULL UNIQUE,
èmail` VARCHAR(75) NULL UNIQUE,
`Funcionario` INT NULL,
PRIMARY KEY (ìdFuncionario`),
INDEX `fk_Funcionarios_Funcionarios_idx` (`Funcionario` ASC),
CONSTRAINT `fk_Funcionarios_Funcionarios`
FOREIGN KEY (`Funcionario`)
REFERENCES `belapadaria`.`Funcionarios` (ìdFuncionario`)
ON UPDATE CASCADE
ON DELETE SET NULL )
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `belapadaria`.`Clientes`

-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `belapadaria`.`Clientes` (
ìdCliente` INT NOT NULL AUTO_INCREMENT ,
`nrCartaoCidadao` INT(8) NULL UNIQUE,
`nome` VARCHAR(75) NULL,
`nrContribuinte` INT(9) NULL UNIQUE,
`dataNascimento` DATE NULL,
`codPostal` VARCHAR(8) NULL,
`rua` VARCHAR(75) NULL,
`concelho` VARCHAR(75) NULL,
`telemovel` INT(9) NULL,
èmail` VARCHAR(75) NULL UNIQUE,
PRIMARY KEY (ìdCliente`))
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `belapadaria`.`Pedidos`

54
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `belapadaria`.`Pedidos` (

ìdPedido` INT NOT NULL AUTO_INCREMENT ,
`valor` DECIMAL(7,2) NOT NULL CHECK (valor>0),
`dataHora` DATETIME NOT NULL,
`Cliente` INT NOT NULL,
PRIMARY KEY (ìdPedido`),
INDEX `fk_Pedidos_Clientes1_idx` (`Cliente` ASC),
CONSTRAINT `fk_Pedidos_Clientes1`
FOREIGN KEY (`Cliente`)
REFERENCES `belapadaria`.`Clientes` (ìdCliente`)
ON UPDATE CASCADE
ON DELETE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `belapadaria`.`Produtos`

-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `belapadaria`.`Produtos` (
ìdProduto` INT NOT NULL AUTO_INCREMENT,
`nome` VARCHAR(75) NOT NULL,
`preco` DECIMAL(7,2) NOT NULL CHECK (preco>0),
`duracao` TIME NULL,
`stock` INT(10) NOT NULL CHECK (stock>=0),
PRIMARY KEY (ìdProduto`))
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `belapadaria`.`FuncionariosPedidos`

-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `belapadaria`.`FuncionariosPedidos` (
`Funcionario` INT NOT NULL,
`Pedido` INT NOT NULL,
PRIMARY KEY (`Funcionario`, `Pedido`),
INDEX `fk_Funcionarios_has_Pedidos_Pedidos1_idx` (`Pedido` ASC),
INDEX `fk_Funcionarios_has_Pedidos_Funcionarios1_idx` (`Funcionario` ASC),
CONSTRAINT `fk_Funcionarios_has_Pedidos_Funcionarios1`
55

ON UPDATE CASCADE
ON DELETE CASCADE,
CONSTRAINT `fk_Funcionarios_has_Pedidos_Pedidos1`
FOREIGN KEY (`Pedido`)
REFERENCES `belapadaria`.`Pedidos` (ìdPedido`)
ON UPDATE CASCADE
ON DELETE CASCADE)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `belapadaria`.`PedidosProdutos`

-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `belapadaria`.`PedidosProdutos` (
`Pedido` INT NOT NULL,
`Produto` INT NOT NULL,
`quantidade` INT(7) NOT NULL,
PRIMARY KEY (`Pedido`, `Produto`),
INDEX `fk_Pedidos_has_Produtos_Produtos1_idx` (`Produto` ASC),
INDEX `fk_Pedidos_has_Produtos_Pedidos1_idx` (`Pedido` ASC),
CONSTRAINT `fk_Pedidos_has_Produtos_Pedidos1`
FOREIGN KEY (`Pedido`)
REFERENCES `belapadaria`.`Pedidos` (ìdPedido`)
ON UPDATE CASCADE
ON DELETE CASCADE,
CONSTRAINT `fk_Pedidos_has_Produtos_Produtos1`
FOREIGN KEY (`Produto`)
REFERENCES `belapadaria`.`Produtos` (ìdProduto`)
ON UPDATE CASCADE
ON DELETE CASCADE)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `belapadaria`.`ClientesProdutos`

-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `belapadaria`.`ClientesProdutos` (
`Cliente` INT NOT NULL,
56
PRIMARY KEY (`Cliente`, `Produto`),

INDEX `fk_Clientes_has_Produtos_Produtos1_idx` (`Produto` ASC),
INDEX `fk_Clientes_has_Produtos_Clientes1_idx` (`Cliente` ASC),
CONSTRAINT `fk_Clientes_has_Produtos_Clientes1`
FOREIGN KEY (`Cliente`)
REFERENCES `belapadaria`.`Clientes` (ìdCliente`)
ON UPDATE CASCADE
ON DELETE CASCADE,
CONSTRAINT `fk_Clientes_has_Produtos_Produtos1`
ON UPDATE CASCADE
ON DELETE CASCADE)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `belapadaria`.`FuncionariosProdutos`

-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `belapadaria`.`FuncionariosProdutos` (
`Funcionario` INT NOT NULL,
`quantidade` INT NOT NULL,
`dataConfe` DATE NULL,
PRIMARY KEY (`Funcionario`, `Produto`),
INDEX `fk_Funcionarios_has_Produtos_Produtos2_idx` (`Produto` ASC),
INDEX `fk_Funcionarios_has_Produtos_Funcionarios2_idx` (`Funcionario` ASC),
CONSTRAINT `fk_Funcionarios_has_Produtos_Funcionarios2`
ON UPDATE CASCADE
ON DELETE CASCADE,
CONSTRAINT `fk_Funcionarios_has_Produtos_Produtos2`
ON UPDATE CASCADE
ON DELETE CASCADE)
ENGINE = InnoDB;
57
SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
58
II. Anexo Script completo do Povoamento da

BelaPadaria
-- Universidade do Minho
-- Mestrado Integrado em Engenharia Informtica
-- Unidade Curricular de Bases de Dados
-- 2015/2016
-- drop database belapadaria;
-- DELETE FROM funcionarios;
USE `belapadaria` ;
-- SET SQL_SAFE_UPDATES = 0;
-- DELETE FROM produtos;

INSERT INTO produtos
(idProduto, nome, preco, duracao, stock)
VALUES
(1, 'po de milho', 3.2 , 1000, 200),
(idProduto,'bijou',0.2,1500,600),
(idProduto, 'cacete', 0.80, 1800, 630),
(idProduto, 'broa de centeio', 2.5, 1000, 310),
(idProduto, 'baguete',0.40, 1800, 500),
(idProduto, 'trigo', 0.10, 950, 1000),
(idProduto, 'pao de forma', 1.20, 1321, 100),
(idProduto, 'po preto', 2.85, 2000, 150),
(idProduto, 'pao sirio',4.0, 1000, 320),
(idProduto, 'po mistura', 2.4, 1800, 125),
(idProduto, 'croissants', 0.75, 2000, 46 ),
(idProduto, 'bolas de berlim',1.10, 1256, 65),
(idProduto, 'muffin', 0.7, 1900, 23),
59
(idProduto, 'bolo de arroz', 0.5, 1327, 13),

(idProduto, 'bolo brigadeiro', 1.20, 1658, 46),
(idProduto, 'panike', 0.8, 623, 100),
(idProduto, 'po de l de Ovar', 10.00, 2500, 50 ),
(idProduto, 'bolas integrais', 0.85, 2653, 210),
(idProduto, 'po com chourio', 1.00, 1856, 65),
(idProduto, 'pastel de nata', 1.00, 2100, 150),
(idProduto, 'tarte de morango', 6.00, 3215, 20),
(idProduto, 'tarte de amendoa', 7.00, 2500, 15);
-- SELECT * FROM produtos;
-- DELETE FROM clientes;

INSERT INTO clientes
(idCliente,nrCartaoCidadao,nome,
nrContribuinte,dataNascimento,codPostal,rua,concelho,telemovel,email)
VALUES
(1,14344154,'Clia Figueiredo', 262646080, '1994-05-21', '4755-128', 'Rua da Costa',
'Barcelos',933337717,'celianlf@hotmail.com'),
(idCliente,14256546,'Silvia Figueiredo', 262646170, '1990-08-01', '4755-128', 'Rua da Coutada',
'Barcelos',934885969,'silvialfg@hotmail.com'),
(idCliente,14513924,'Daniel Rodrigues', 243519145, '1994-01-31', '4830-274', 'Rua dos
Condes', 'Povoa de Lanhoso',945434241,'danysuica@hotmail.com'),
(idCliente,14628648,'Patricia Barros', 252636450, '1994-02-24', '4970-129', 'Rua da Cachada',
'Arcos de Valdevez',934947881,'padb7@hotmail.com'),
(idCliente,14646469,'Mrcia
Costa',
246464646,
'1994-01-21',
'4710-416',
'Rua
dos
Pees','Braga',933337681,'mmcostinha@gmail.com'),
(idCliente,14425150,'Xavier Francisco', 258903384, '1994-11-10', '2495-183', 'Rua da Central',
'Leiria',912845563,'xavier.n.francisco@gmail.com'),
(idCliente,14256545,'Maria Linda', 562345089, '1989-12-25', '4755-117', 'Rua da Quinto',
'Barcelos',919568697, 'marialinda@hotmail.com'),
(idCliente,13142598,'Pedro Miguel', 232524089, '1994-06-06', '4890-123', 'Rua da Cortina',
'Guimares',936575075,'celianlfg@hotmail.com'),
(idCliente, 65752855, 'Acacio Reino', 236896573, '1990-06-01','4789-456', 'Rua das Camlias',
'Braga', 936545623, 'acacioreino@gmail.com'),
(idCliente,41988997, 'Afonso Felipe', 255590195, '1978-06-16', '4659-489','Rua Doutor
Fernando Santos', 'Braga', 919636489, 'afonsofilipe@hotmail.com'),
(idCliente,66813274, 'Aida Figueira', 234117754 , '1950-01-31', '4632-488','Rua Martins S',
'Guimares', 969596989, 'aidafigueira@gmail.com'),
60
(idCliente, 21166885,'Alzira Branco', 212100348, '1965-02-05','4698-420', 'Rua das Manteigas',

'Povoa de Lanhoso', 919596638, 'alzbranco@gmail.com'),
(idCliente, 59289948, 'Amanda Collao', 248562163, '1978-02-04', '4963-023', 'Rua do Areal',
'Braga', 936569638, 'amanda@gmail.com'),
(idCliente,
82069345, 'Araribia Lages', 230799642, '1989-02-06','4652-365','Rua Principal',
'Ponte da Barca', 936598045, 'lages@gmail.com'),

(idCliente,
87303557 , 'Aurlio Alencar',
216271968, '1979-02-07', '4569-123', 'Rua Santa
Clara', 'Braga', 919895941, 'aurelioalencar@hotmail.com'),

(idCliente, 77850320 , 'Barnab Maia', 258732863 , '1965-05-05', '4658-046', 'Rua Carris',
'Ponte da Barca', 910023659, 'barnabe@gmail.com'),
(idCliente, 87234908, 'Camilo Castelo Branco', 254983529, '1957-09-06', '4986-056', 'Rua da
Costa ', 'Ponte de Lima', 929695963, 'camilo@gmial.com'),
(idCliente, 75490443, 'Carmem
Eir', 211043896, '1968-09-06',
'4755-118',
'Rua do
computador', 'Ponte de Lima', 919796364, 'carmeneiro@gmail.com'),

(idCliente, 14906449, 'Ceclia Moita', 225505091,'1945-06-06', '4755-136', 'Rua dos cornudos',
'Braga', 919895032, 'cecilia@gmial.com' ),
(idCliente, 73530459,'Celso Nieves', 238394802, '1978-07-07', '4769-123', 'Rua de Remelhe',
'Braga', 963126799, 'celsoneves@gmail.com'),
(idCliente, 55905558, 'Ceclia Amorn', 228393850, '1946-05-05', '4754-145', 'Rua dos Olivais',
'Braga', 926364501, 'ceciliamoites@gmail.com'),
(idCliente, 70364642, 'Cam Barateiro', 245843773, '1976-05-06', '4659-145', 'Rua do
Ramalhete', 'Vila Verde', 925468456, 'caimbarateiro@gmail.com' ),
(idCliente, 59193671, 'Brenda Eir', 216255827,'1978-09-25','4758-118', 'Rua da Angola', 'Vila
Verde', 923659874, 'brendaeiro@gmail.com'),
(idCliente, 17604812,'Berengria Capistrano', 244020132, '1980-03-26', '4632-089', 'Rua dos
Congregados', 'Braga', 919362032, 'capistrano@gmail.com'),
(idCliente,
77563243
,'Cleiton
Dmaso',
230040906,'1946-04-06','4789-063',
'Rua
dos
pimentos', 'Braga', 919666320, 'cleitondamaso@gmail.com'),

(idCliente, 59263645, 'Constana Bezerra', 219881747, '1989-09-09', '4569-230', 'Rua dos
livros', 'Braga', 919632555, 'constanca@gmail.com'),
(idCliente, 64891283 , 'Cristiana Camelo', 249082277 , '1955-03-01', '4980-053', 'Rua da Fonte',
'Arcos de Valdevez', 963222032, 'cristianocamelo@gmail.com'),
(idCliente, 42690311,'Cndido Cordero', 225553173, '1946-06-04', '4986-012', 'Rua da Fiona',
'Braga', 912333650, 'cordero@gmail.com' ),
(idCliente, 38243651, 'Dinis Silveira dos Aores',
243459649 , '1963-06-06','4695-569',
'Travessa Cruz da Argola','Braga', 912365445, 'dinisacores@gmail.com'),

(idCliente, 48779571, 'Dorindo Bautista', 235346313, '1989-12-12', '4610-050', 'Rua do
Montinho' , 'Guimares', 932336520, 'dorindo@gmail.com'),
(idCliente, 21458549, 'Else Costa',
224673769, '1981-07-26', '4810-050', 'Rua Jos Faria
Martins', 'Guimares', 938971033, 'elsetintascompinta@hotmail.com'),

61
(idCliente, 63302315, 'Dlio Valadares', 259684559, '1966-11-11', '4695-023', 'Rua Adamastor',

'Guimares', 963126755, 'deliovaladares@gmail.com' ),
(idCliente, 24630583 , 'Enia
Godinho', 240731124, '1967-12-15', '4932-563', 'Rua dos lafes',
'Vila Nova de Famalico', 936333014, 'eniagod@hotmail.com' ),

(idCliente,
58402102,'Fausto Bezerril',
245911111 , '1965-05-24', '4965-365', 'Rua das
Camlias', 'Braga', 931125563, 'faustobezerril@gmail.com' ),

(idCliente, 29678505, 'Felisbela Barroqueiro0', 251677164, '1945-03-03', '4765-012', 'Travessa
da igreja', 'Braga', 923666320, 'felisbelabar@gmail.com'),
(idCliente, 20737619 ,'Ferno Mesquita', 258487592 , '1940-09-15', '4978-026', 'Travessa dos
mosqueteiros', 'Braga', 936363203, 'fernaomesq@gmail.com'),
(idCliente, 54660207,'Filipa Moita', 231508952 , '1949-03-06', '4965-001', 'Rua Cames',
'Braga', 933331236, 'filipamota@gmail.com'),
(idCliente, 61590065 , 'Filomena Vicario', 228505066, '1976-10-05', '4755-129', 'Rua D.Joo
IV', 'Porto', 919998632, 'filomenavica@gmail.com' ),
(idCliente, 37447762 , 'Fulvio lvarez', 212368844 , '1954-04-29', '4321-603', 'Rua Padre
Henrique', 'Porto', 936569874, 'fulviolavarez@gmail.com'),
(idCliente,
74539809 , 'Ftima Quinzeiro', 237361232, '1973-10-23', '4895-236', 'Rua das
Marias', 'Porto', 964456320, 'fatimaquinz@gmail.com'),

(idCliente, 31543274, 'Gedeo Piteira', 223094652, '1968-08-08', '4769-961', 'Rua Milionrio',
'Porto ', 912223650, 'gedeaopiteira@gmail.com'),
(idCliente, 53034102, 'Genoveva Atade', 215529801, '1978-09-06', '4956-025', 'Rua da Luz',
'Porto', 926565320, 'genovevaataide@gmail.com'),
(idCliente, 61953014 , 'Gertrudes Serralheiro', 226703667, '1975-06-03', '4563-029', 'Rua dos
pneus', 'Porto', 912236603, 'gertrudesserral@gmail.com'),
(idCliente, 48819960 , 'Gilberto Arago', 248185990, '1989-07-08', '4569-147', 'Rua Gil Eanes',
'Porto', 932635632, 'gilbertoaragao@gmail.com'),
(idCliente, 75892799, 'Gilberto Hidalgo', 249343033, '1959-09-28', '4956-110', 'Rua Vasco da
Gama', 'Aveiro', 963332145, 'gilbertohidalgo@gmail.com'),
(idCliente, 28212437, 'Graa Lameiras', 249680555, '1978-10-11', '4112-456', 'Praceta Goa',
'Aveiro', 912366658, 'gracalameira@gmail.com' ),
(idCliente, 40421771, 'Guaraci Henriques', 221772118, '1957-12-10','4756-012', 'Rua Guin
Bissau', 'Aveiro', 933365569, 'guaracihenr@gmail.com'),
(idCliente, 10258345, 'Guterre Nbrega', 231098939, '1978-10-21', '3800-510', 'Rua da
Liberdade','Aveiro', 912256302, 'guterresno@hotmail.com' ),
(idCliente, 85644722, 'Helosa Barros', 243678919, '1981-02-24', '3845-520', 'Rua 1 de Maio',
'Pvoa de Varzim', 936632014, 'heloisabarros@gmail.com'),
(idCliente, 62789072, 'Herculano Rosrio', 26634814, '1967-06-08', '3846-456', 'Rua de milho',
'Pvoa de Varzim', 912256301, 'herculanorosa@gmail.com' ),
(idCliente, 92883492 , 'Heriberto Vega', 247026870 , '1979-05-26', '3465-489', 'Rua dos
Combatentes', 'Fafe', 919898638, 'heribertovega@hotmail.com'),
62
(idCliente, 28459026 , 'Irene Cayubi', 256196917, '1970-05-13', '3956-102', 'Rua das Flores',
'Aveiro', 912365698, 'irenecay@gmail.com'),
(idCliente, 31133069, 'Isaura Fraga', 216794139 , '1971-09-29', '3789-036', 'Rua dos Canteiros
da Igreja', 'Porto', 936632220, 'isaurafraga@gmail.com'),
(idCliente, 55387861 , 'Isilda Louzada',
220006450 , '1978-08-25', '4698-456','Rua das
Camlias','Braga', 915569874, 'isildalos@hotmail.com' ),

(idCliente,
28066071, 'Jandira Fuentes', 238509303, '1979-09-06', '4956-113', 'Rua dos
Campees', 'Porto', 936523652, 'jandirafuentes@gmail.com'),

(idCliente, 86288833, 'Jonas Salto', 214500324, '1972-10-30', '4980-005', 'Ruas das
Catarinas', 'Porto', 963166320, 'jonasaltao@gmail.com'),
(idCliente,
29896435, 'Joo Murtinho',
214754691, '1979-10-10', '4896-123', 'Rua dos
mosqueteiros', 'Porto', 936565230, 'joaomurtinho@gmial.com'),

(idCliente,
32089958, 'Jssica Abasto',
230792216, '1980-10-06', '4979-125', 'Rua dos
aquecedores', 'Porto', 912223547, 'jessicaabasto@gmail.com'),

(idCliente, 53165146, 'Levi Caiap',
210508385, '1958-10-13', '4700-125', 'Rua dos sofs',
'Porto', 936656320, 'levicaia@gmail.com'),

(idCliente, 86804958, 'Lina Bulhosa', 214973412, '1973-12-05', '4752-478', 'Rua da Boavista',
'Porto', 919696320, 'linabulhosa@gmial.com'),
(idCliente, 97588097, 'Luzia Barretto', 219322680, '1986-12-03', '4563-333', 'Rua da Silvia',
'Braga', 929696301, 'luziabarreto@gmail.com'),
(idCliente, 49686083, 'Lus Lamego',
209103457, '1962-01-03', '4963-160', 'Rua das
televises', 'Braga', 919596989, 'luislamego@hotmial.com'),

(idCliente, 57264248 , 'Lia Godoi', 218642117, '1974-05-27', '4698-456', 'Rua dos patetas',
'Porto', 919696324, 'leiagodi@gmail.com' ),
(idCliente, 41363446, 'Lvia Beserril', 244078522, '1971-03-26', '4698-114', 'Rua Antonio
Campos', 'Braga', 933365447, 'liviabase@gmail.com'),
(idCliente, 26081466, 'Marcelo Colao', 230013263, '1995-10-06', '4750-63', 'Rua Martins de
S', 'Barcelos', 934885620, 'marceloscolaco@gmail.com'),
(idCliente, 50091477, 'Marco Assis', 234882607, '1990-01-06', '4796-118' ,'Rua do Marcelo
Marcelino', 'Barcelos', 936654102, 'marcoassis@hotmail.com'),
(idCliente,
77434812,'Moiss Mourato',
250448213, '1976-06-28', '4950-005', 'Rua das
candeias', 'Braga', 919633210, 'moisesmourato@gmail.com'),

(idCliente, 54203565, 'Moiss Paio', 258916186, '1959-12-26', '4520-220', 'Rua das
sapatilhas', 'Braga', 919987441, 'moisespaiao@gmail.com'),
(idCliente, 14993103, 'Morgana Nieto', 258979151, '1979-06-28', '4693-009', 'Rua dos paus',
'Porto', 919952012, 'morgananieto@hotmail.com'),
(idCliente, 42325186, 'Mxima Gallindo', 210239403, '1989-09-09', '3900-145', 'Rua dos
pessegos', 'Braga', 936523023, 'maximagall@gmail.com'),
(idCliente, 83964441, 'Nicolau Pessoa', 256107368, '1976-05-10', '3956-056',
palhaos', 'Porto', 966654230, 'nicolaupessoa@hotmail.com'),
63
'Rua dos
(idCliente, 72563775, 'No Amaro',
239787750, '1970-12-31', '3900-009', 'Rua das Portas
Partidas', 'Porto', 912223658, 'noemaoro@gamil.com'),

(idCliente, 84869974, 'No Matoso', 222031717, '1976-06-09', '3795-026', 'Rua Santa Brbara',
'Porto', 918856320, 'noematoso@hotmail.com'),
(idCliente, 64530325 , 'Olavo Regalado', 249041833, '1988-10-12', '4006-026', 'Avenida da
Liberdade', 'Braga', 936666523, 'olavoregalo@hotmail.com'),
(idCliente, 97987526, 'Ondina Fonseca', 230863795, '1989-10-01', '4700-060', 'Rua das
Canetas', 'Porto', 919192936, 'ondinafonseca@gmail.com'),
(idCliente, 82403162, 'Parcidio Santos',
210384949, '1987-07-08', '3926-056', 'Rua dos
Abades', 'Braga', 933365478, 'parcisiosantos@gmail.com'),

(idCliente, 80122799, 'Plnio Souto', 247125019, '1975-05-25', '4900-118', 'Rua do Bairro Frio',
'Barcelos', 919666547, 'pliniosouto@gmail.com' ),
(idCliente, 22068561,'Raul Abranches', 255587146, '1980-05-29', '4962-089', 'Rua do co lindo',
'Porto', 929632301, 'raulabranches@gmail.com'),
(idCliente, 19955704, 'Ricardo Abreu', 258299270, '1976-10-21', '4760-220', 'Rua dos meninos
lindos', 'Porto', 919693201, 'ricardoabreu@gmail.com'),
(idCliente, 49415844, 'Rita Granjeiro', 217637687, '1980-01-28', '3500-110', 'Rua do Sol do
co', 'Porto', 919654487, 'ritagrangeiro@gmail.com' ),
(idCliente, 67642994, 'Ronaldo Neto', 225708936, '1993-06-29', '4750-042', 'Rua do Sado',
'Aveiro', 939669321, 'ronaldoneto@gmail.com'),
(idCliente, 28876313, 'Rubim Lopes', 252634214, '1990.09-26', '4569-117', 'Rua do Lobarinhas',
'Barcelos', 939632114, 'rubimlopes@gmail.com'),
(idCliente, 32385660, 'Selma Rico', 245116940, '1954-10-01', '4750-154', 'Rua do Hospital',
'Barcelos', 929632145, 'selmarico@gmail.com'),
(idCliente, 30025843, 'Simeo Paula', 237751261, '1988-08-28', '4755-125', 'Rua da Julia
Pinheiro', 'Braga', 919995874, 'simeaopaula@gmail.com'),
(idCliente, 82040713, 'Sofia Meneses', 211857717, '1990-10-18', '3923-256', 'Rua das
Carteiras', 'Barcelos', 929696325, 'sofiameneses@gmail.com'),
(idCliente,69715916,'Jlio
Figos',239580157,'2002-12-11','4835-052','Rua
das
Violetas','Guimares',969654555,'jujufigos@hotmail.com'),
(idCliente,28778883,'Amlia Costa',223050562,'1989-10-10','3800-032','Rua do Rei','Viana do
Castelo',939564525,'amaliacostinha@yahoo.com'),
(idCliente,76460503,'Henrique Alburqueque',252339592, '1979-11-26', '3455-489', 'Rua dos
Combatentes', 'Fafe', 912211662, 'heriqueque@hotmail.com'),
(idCliente,54808239,'Susana Freitas',228058672,'1990-02-18','3820-416','Rua Mousinho da
Silveira','Aveiro',939998452,'sufrei@yahoo.com'),
(idCliente,12723975,'Cludia
Mendes',245217670,'2000-02-03','4035-025','Rua
das
Amoreiras','Lisboa',912103254,'mendeslau9@hotmail.com'),
(idCliente,72520958,'Joel
Freitas',220720397,'1992-06-01','4800-050','Rua
Rossio','Lisboa',969654148,'jufreitas@gmail.com'),
64
do
(idCliente,35078862,'Celina
Melo',241573795,'1990-03-02','4810-023','Rua
25
de
Abril','Porto',966659032,'melo11@gmail.com'),
(idCliente,50007458,'Eduardo
Almeida',232152526,'1999-09-12','3835-023','Rua
Central
3','Fafe',939365472,'edu_al_meida@gmail.com'),
(idCliente,24038347,'Ana
Joo
Castro',246336500,'1994-06-15','4835-005','Rua
de
'2000-01-01','3805-155','Avenida
da
Janeiro','Braga',918542013,'castro_ana34@hotmail.com'),
(idCliente,97767537,'Zita
Cerqueira',
217587087,
Guerra','Porto',939352012,'zzitac_5@gmail.com'),
(idCliente,72682483, 'lvaro Passos', 217484621 , '1988-09-13', '4800-212', 'Rua Soares dos
Santos ', 'Famalico', 912296364, 'passos88@hotmail.com'),
(idCliente,72682480, 'Manuel Mendes', 249807888 , '1998-09-13', '4850-211', 'Rua Sol do Ave ',
'Fafe', 932296304, 'manuelfmendes8@hotmail.com'),
(idCliente,67939759, 'rtur Fonseca', 240020325 , '1978-10-13', '4610-561', 'Rua Soares Abreu
', 'Felgueiras', 966296364, 'arturfonfon@hotmail.com'),
(idCliente, 66097075, 'Vitor Ferreira', 232536798, '1992-03-03', '4800-321', 'Rua dos Santos
Populares ', 'Famalico', 922206364, 'ferreira65@hotmail.com'),
(idCliente, 23656282, 'Diogo Costa', 252918603, '1984-08-11', '4710-417', 'Rua Soares dos
Santos ', 'Braga', 912246364, 'dicosta@hotmail.com');
-- SELECT * FROM clientes;
-- DELETE FROM pedidos

INSERT INTO pedidos
(idPedido, valor, dataHora, Cliente)
VALUES
(1, 0, '2015-10-01 10:00:00', 1),
(idPedido, 0, '2015-11-03 11:01:23', 2),
(idPedido, 0, '2015-12-03 12:12:53', 3),
(idPedido, 0, '2015-12-10 14:10:05', 4),
(idPedido, 0, '2015-12-20 15:21:23', 50),
(idPedido, 0, '2015-12-21 15:25:00', 5),
(idPedido, 0, '2015-12-23 16:20:56', 6),
(idPedido, 0, '2015-12-24 16:20:47', 7),
(idPedido, 0, '2015-12-24 17:05:56', 8),
(idPedido, 0, '2015-12-24 17:09:53', 9),
(idPedido, 0, '2015-12-24 18:01:02', 10),
(idPedido, 0, '2015-12-24 18:04:36', 12),
(idPedido, 0, '2015-12-24 18:08:39', 13),
(idPedido, 0, '2015-12-24 18:15:49',14),
(idPedido, 0, '2015-12-24 18:20:50',15),
65
(idPedido, 0, '2015-12-24 18:25:46',16),

(idPedido, 0, '2015-12-24 18:30:32',17),
(idPedido, 0, '2015-12-24 18:45:46',18),
(idPedido, 0, '2015-12-24 18:50:54',19),
(idPedido, 0, '2015-12-26 09:08:03',20),
(idPedido, 0, '2015-12-26 09:20:06',21),
(idPedido, 0, '2015-12-26 10:21:09',53),
(idPedido, 0, '2015-12-26 15:15:15',22),
(idPedido, 0, '2015-12-26 18:25:39',23),
(idPedido, 0, '2015-12-27 15:46:48',24),
(idPedido, 0, '2015-12-28 09:06:03',25),
(idPedido, 0, '2015-12-29 11:11:11',26),
(idPedido, 0, '2015-12-30 15:06:09',27),
(idPedido, 0, '2015-12-31 17:56:58',28),
(idPedido, 0, '2016-01-03 09:25:00',29);
-- SELECT * FROM pedidos
-- DELETE FROM pedidosprodutos

INSERT INTO pedidosprodutos
(Pedido, Produto, quantidade)
VALUES
(1,1, 2),
(1,6, 2),
(2,2, 5),
(2,10, 9),
(2,8, 5),
(3,1, 1),
(4,3, 10),
(5,8, 12),
(6,14, 2),
(7, 4, 3),
(8, 21, 1),
(8, 2, 1),
(8,5,4),
(9,13, 5),
(9, 12, 5),
(10,14,2),
(10,13,2),
66
(11, 22, 1),

(11, 6, 3),
(12, 8, 1),
(13, 9, 6),
(14, 10, 6),
(15, 19, 2),
(16, 16, 4),
(17,6, 3),
(18, 9, 8),
(19, 9, 8),
(30, 21, 2),
(30, 2, 3);
-- SELECT * FROM pedidosprodutos
-- DELETE FROM funcionarios;

INSERT INTO funcionarios
(idFuncionario,horario,nib,salario,nome,nrContribuinte,dataNascimento,nrCartaoCidadao,
nrPorta,rua,freguesia,concelho,distrito,codPostal,telemovel,telefone,facebook,email,Funcionario
)
VALUES
(1,
'1',003589657632569874569,
2000,
'Clia
Figueiredo',
262646080,
'1993-02-
02',14384155,27,' Rua da Costa',

'Chorente',
'Barcelos',
'Braga','4755-118',
919568697,
'252957073',
'https://www.facebook.com/celianlfg','celianlgh@hotmail.com', null),
(idFuncionario, '2',032565658456985698563, 1100, 'Jos Joo', '262646210', '1993-0329',16254896,2569,' Rua da Quint', 'Remelhe',
'Barcelos', 'Braga', '4625-485', 926354789, 253808909, 'https://www.facebook.com/JosJoo',
'jj@gmail.com', null),
(idFuncionario, '1',123568466569874563210, 850, 'Carlos Daniel', 264646200, '1993-09-22','
14384154', 93,'Rua da Calada',
'Courel','Barcelos',
'Braga',
'4589-129',
911171046,
'252957056','https://www.facebook.com/carlosDaniel', 'carlosdaniel@live.com.pt', 1),

(idFuncionario, '1',653245689899963200124, 850, 'Adriana Pereira', 262646200, '1993-0808',14365163,1200, 'Rua Padre Confucio da Silva',
'Covas
do
Barroso',
'Boticas',
'Vila
Real',
'4068-110',
934885521,
258657079,'https://www.facebook.com/AdrianaPereira', 'adrianpereira_7@hotmail.com', 2),

(idFuncionario, '1',896324778118118118118, 650, 'Marcus Costa', 262646118, '1990-0201',14568974,118, 'Rua Central',
67
'Carvalhas','Amares',
'Braga','4720-118',963126744,
257527118,'https://www.facebook.com/MarcusCosta','marcuscosta@gmail.com', 2),
(idFuncionario, '3',123123123123123123123, 1090, 'Lus Oliveira', 245689056, '1989-0622','13459687',56,'Rua das Cancelinhas',
'Oliveira Santa Maria','Vila Nova Famalicao','Porto', '4899-123', 915325568, 252951987,
'https://www.facebook.com/LuisCarlosRoqueOliveira','luis.roqueoliveira@gmail.com', 1),
(idFuncionario, '2', 123654789632023654569, 1500, 'Mrcia Costa', 252646260, '1994-0121',14513294, 46, 'Rua do Rio Alto', 'Alto',
'Pvoa
de
Varzim',
'Porto',
'4490-002',
919299987,
253419557,
'https://www.facebook.com/marciacosta46', 'mmcostinha@gmail.com', 1),

(idFuncionario, '3', 003565477800012365478, 1090, 'Manuel Faria', 262516046, '1992-07-18',
14984561, 1569, 'Rua da Igreja Velha',
'Tabuadelo',
'Guimares',
'Braga',
'4835-599',
252369896,'https://www.facebook.com/manuelfaria', 'manuelfaria@gmail.com', 2 );
-- SELECT * FROM funcionarios;
-- DELETE FROM funcionariosprodutos;

INSERT INTO funcionariosprodutos
(Funcionario, Produto, quantidade, dataConfe)
VALUES
(4, 1, 200, '2015-12-24'),
(4, 2, 700, '2015-12-29'),
(4, 3, 700, '2015-12-30'),
(4, 11,30, '2015-12-30'),
(4, 12, 70, '2016-01-02'),
(5, 13, 25, '2016-01-02'),
(5, 4, 400, '2016-01-02'),
(5, 5, 500,'2016-01-02'),
(5, 6, 1500, '2016-01-02'),
(5, 7, 150, '2016-01-02'),
(5, 8, 200, '2016-01-03'),
(5, 17, 60, '2016-01-03'),
(6, 9, 400, '2016-01-03'),
(6, 10, 190, '2016-01-03'),
(6, 14, 30, '2016-01-03'),
(6, 15, 50, '2016-01-04'),
(6, 16, 150, '2016-01-04'),
(3, 18, 250, '2016-01-04'),
(3, 19, 70, '2016-01-04'),
68
933365236,
(3, 20, 160, '2016-01-04'),

(3, 21, 25, '2016-01-04'),
(3, 22, 30, '2016-01-05'),
(7, 21, 25, '2016-01-06'),
(7, 6, 1400, '2016-01-06'),
(7, 8, 150, '2016-01-06'),
(7, 4, 350, '2016-01-06');
-- SELECT * FROM funcionariosprodutos;
-- DELETE FROM funcionariospedidos;

INSERT INTO funcionariospedidos
(Funcionario,Pedido)
VALUES
(1, 1), (1, 4), (1, 3),
(1, 5), (2, 7), (3, 8),
(1,9), (1,10), (2, 11),
(3, 12), (1, 13), (2,14),
(1,15), (2, 16), (3,17),
(1, 18), (2, 19), (1,20),
(2,21), (3, 22), (8, 23),
(2, 24), (1, 25), (2,26),
(3,27), (1,28), (2,29),
(3,30), (1, 2), (2, 6);
-- SELECT * FROM funcionariospedidos;
-- DELETE FROM clientesprodutos;

INSERT INTO clientesprodutos
(Cliente, Produto)
VALUES
(1, 1),
(1, 2),
(2, 20),
(3, 3),
(4, 9),
(5, 21),
(6, 7),
(7, 18),
69
(8, 19),
(9, 6),
(10, 21),
(11, 9),
(12, 10),
(13,10),
(14, 1),
(15, 5),
(16, 15),
(16, 1);
70

Relatorio BD1516-Grupo28

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Relatorio BD1516-Grupo28

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade do Minho

Clia Natlia Lemos Figueiredo (a67637),

Clia Natlia Lemos Figueiredo (a67637),

contextualizao do projeto, motivao e objetivos, anlise de requisitos e a estrutura do

rea de Aplicao: Desenho e arquitetura de Sistemas de Bases de Dados.

1.2. Apresentao do Caso de Estudo

1.3. Motivao e Objetivos

1.4. Estrutura do Relatrio

2. Anlise e levantamento de requisitos

3. Modelo Conceptual da Base de Dados

3.1. Identificar as entidades do problema

3.1.5 Dicionrio de dados das entidades

3.2. Identificar tipos de relacionamentos

3.2.1 Dicionrio de dados dos relacionamentos

3.3. Identificar e relacionar atributos com as entidades e tipos de relacionamentos/

3.3.1 Dicionrio de dados dos atributos das entidades

3.3.2 Dicionrio de dados dos atributos das relaes

3.4. Determinar chaves candidatas, primrias e alternadas

3.5. Considerar o uso de modelao avanada

3.6. Verificar que no existem redundncias no modelo

3.7. Validar Modelo com perguntas do utilizador

3.8. Rever e validar o Modelo com o Utilizador

4.1. Derivao das relaes para o modelo lgico

4.2. Validao das relaes atravs da normalizao

4.2.1 1FN 1 Forma Normal

4.2.2 2FN 2 Forma Normal

4.2.3 3FN 3 Forma Normal

4.3. Validao das relaes atravs das transaes dos utilizadores

4.4. Anlise das restries de integridade

4.5. Reviso do modelo lgico com o utilizador

4.6. Anlise do crescimento futuro

5.1. Traduo do modelo lgico para o SGBD escolhido

5.1.1 Desenho das relaes base

5.1.2 Desenho das representaes dos dados derivados

5.1.3 Desenho das restries gerais

5.2. Organizao dos ficheiros e ndices

5.2.1 Anlise de transaes

5.2.2 Escolha da organizao dos ficheiros

5.2.3 Escolha dos ndices

5.2.4 Estimativa de espao em disco necessrio

5.3. Desenho das vistas de utilizadores

5.4. Mecanismos de segurana

5.5. Considerao de introduo de redundncia controlada

5.6. Monitorizar e afinar o sistema operativo

7. Concluses e Trabalho Futuro

Anexo 1 Script completo da criao do esquema

Anexo Script completo do Povoamento da BelaPadaria

Figura 1 - Esquema conceptual

Figura 2 - Relacionamento entre Entidades

Figura 3 - Diagrama ER com as chaves primrias adicionadas

Figura 4 - Modelo Lgico

Figura 5 - Excerto da script criao da tabela Clientes

Figura 6 - Excerto da script criao da tabela Funcionarios

Figura 7 Excerto da Criao da script criao da tabela Produtos

Figura 8 - Excerto da script de criao da tabela Pedidos

Figura 9 - Script da criao do gatilho "AtualizaValor"

Figura 10 - Criao de um gatilho que permite verificar o limite de idades 39

Figura 12 Criao do procedimento atualizarStockFromFunc

Figura 13 Criao do procedimento substiuFun

Figura 14 - Criao de ndices

Figura 15 - Criao de uma Vista com o preario, visivel para os clientes 45

Figura 18 - Criao de uma vista contendo a informao da relao cliente compra

Tabela 2 - Dicionrio de dados dos relacionamentos