Gestor de Filmes - Relatório Prático

Departamento de Eletrónica, Telecomunica¸cões e Informática
Trabalho Prático Final
Gestor de Filmes
Curso [8240] MI em Engenharia de Computadores e Telemática
Disciplina [42532] Base de Dados
Ano letivo 2015/2016
Alunos [68779] Rui Oliveira
[68287] V´ıtor Barros
Prática P1-G10
Docente Professor Joaquim Sousa Pinto
Aveiro, 10 de Junho de 2016

Conteúdo
1 Introdu¸cão 1
2 Análise de requisitos 1
3 Diagrama Entidade-Rela¸cão 4
4 Modelo Relacional 5
5 T-SQL DDL 6
5.1 Tabelas SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6 T-SQL DML 8
7 Normaliza¸cão 9
8 Stored Procedures 11
9 Views 15
10 UDF’s 15
11 Índices 16
12 Triggers 17
13 Seguran¸ca 18
14 Interface gráfica 19
14.1 Demo - V´ıdeo . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
15 Repositório 23
16 Conclusão 24
17 Referências 24
18 Anexos 24

1 Introdu¸cão
Este trabalho foi realizado no âmbito da unidade curricular Base de Da-
dos do Mestrado Integrado em Engenharia de Computadores e Telemática
da Universidade de Aveiro. O objetivo deste trabalho prático consiste no de-
senvolvimento de uma aplica¸cão com uma interface gráfica que permita uma
intera¸cão do utilizador com uma base de dados SQL Server para manipula¸cão
de dados.
O trabalho que proposémos consistiu numa aplica¸cão que permite gerir
filmes. Esta aplica¸cão foi desenvolvida utilizando WPF1
na linguagem C#
conjuntamente com uma base de dados SQL Server. Através desta aplica¸cão,
o utilizador poderá adicionar os filmes pretendidos, associar-lhe os atores
intervenientes, o diretor, o realizador, o escritor, a companhia de realiza¸cão,
a banda sonora, os trailers, os locais e datas de lan¸camento e os prémios
que recebeu, caso existam. Para além do descrito anteriormente, a nossa
aplica¸cão permite apenas que utilizadores registados possam aceder/alterar
a informa¸cão disponibilizada.
A base de dados existente fornece ferramentas que permitem a cria¸cão,
altera¸cão e consulta da base de dados de forma segura, eficiente e robusta.
Este relatório reflete todos os passos e decisões tomadas na cria¸cão da base
de dados que sustenta o projeto bem como uma descri¸cão das capacidades
da aplica¸cão desenvolvida para o utilizador.
Para a cria¸cão deste projeto foi seguido o processo lecionado nas aulas,
sendo estas as seguintes fases do processo: análise de requisitos, desenho
conceptual, desenho do esquema lógico, desenho do esquema f´ısico e admi-
nistra¸cão.
2 Análise de requisitos
Dada as especifica¸cões principais descritas na introdu¸cão deste relatório,
teremos as seguintes entidades:
• Filme: um determinado filme é caracterizado por uma descri¸cão, uma
categoria, uma classifica¸cão, um titulo, uma dura¸cão, uma companhia
de produ¸cão, as datas de lan¸camento e o(s) prémio(s) ganhos. Possui
ainda os atores intervenientes, o diretor, o realizador, o escritor e uma
banda sonora associada.
• Diretor: é caracterizado por um nome, uma foto, e uma data de
nascimento.
1
Windows Presentation Foundation
1

• Ator: é caracterizado por um nome, uma foto e uma data de nasci-
mento, para além disso inclui uma biografia.
• Escritor: é caracterizado por um nome, uma foto e uma data de
nascimento, para além disso inclui uma biografia.
• Realizador: é caracterizado por um nome, uma foto, e uma data de
nascimento.
• Companhia: é caracterizada por um nome.
• Música: é caracterizada por um titulo, um género, e uma banda/in-
terprete.
• Trailer: é caracterizado por um titulo, uma dura¸cão, uma data de
lan¸camento e o idioma.
• Lan¸camento: é caracterizado por um titulo, uma data e o pa´ıs.
• Prémio: é caracterizado por um tipo, o ano e uma breve descri¸cão.
Foram também registadas algumas especifica¸cões para o desenho concep-
tual:
• Cada filme terá que ter (obrigatoriamente) um ou mais escritores asso-
ciados.
• Cada filme terá que ter (obrigatoriamente) um ou mais atores associa-
dos.
• Cada filme terá que ter um realizador associados (obrigatoriamente).
• Cada filme terá que ter (obrigatoriamente) um ou mais músicas asso-
ciadas - constituindo a banda sonora do filme.
• Cada filme terá que ter um diretor associados (obrigatoriamente).
• Cada filme terá que ter uma companhia associadas (obrigatoriamente).
• Cada filme poderá ter um ou mais trailers associados.
• Cada filme poderá ter um ou mais prémios associados.
• Cada filme poderá ter um ou mais lan¸camentos associados.
• Realizadores, escritores, atores e diretores são todos pessoas!
2

Para além da possibilidade de adi¸cão, esta aplica¸cão também disponibi-
liza a op¸cão de algumas edi¸cões (atores, escritores, realizadores, músicas),
pesquisar filmes e tudo o que a eles está associado, escolhendo a categoria
na qual se pretende pesquisar e preenchendo um dos campos antes de fazer
efetivamente a pesquisa.
As principais tarefas que o utilizador pode encontrar encontram-se des-
critas no seguinte diagrama.
Adicionar Filme
Adicionar Ator
Adiconar Diretor
Adiconar Escritor
Adicionar Realizador
Adicionar Musicas
(banda sonora)
Adiconar Trailer
Adiconar Lançamento
(do filme)
Adiconar Prémios
Pesquisar por Trailer
Pesquisar por Prémios
Pesquisar por Filme
Pesquisar por Diretor
Pesquisar por Musica
Pesquisar por
Lançamento
Pesquisar por Escritor Pesquisar por Realizador
Pesquisar por Ator
Editar Realizador
Editar Ator
Editar Escritor
Editar Musica
Editar Diretor
Figura 1: Casos de utiliza¸cão do sistema
3

3 Diagrama Entidade-Rela¸cão
Depois da análise de requisitos desenhou-se o diagrama entidade rela¸cão
do nosso sistema. Este desenho foi descrito através de um diagrama enti-
dade rela¸cão. No diagrama, foram definidas entidades, atributos, rela¸cões,
cardinalidades e dependências. Os retângulos representam as tabelas exis-
tentes, as elipses os atributos e por fim os losangos representam as rela¸cões
existentes.
Pessoa
Companhia
Escritor
Realizador
Ator
ID
Foto
Data Nascimento
Nome
Diretor
Biografia
Biografia
Tipo
Ano
Descrição
ID
Data
País
Titulo
Nome
ID
Titulo
ID
Duração URL
Data
Idioma
Titulo
ID Género
Interprete
/ Banda
URL
Titulo
Descrição
Classificação
Duração
ID
Prémio
ganhou
Lançamento
tem
Trailer
tem
Músicas
escrito
por
produzido
contém
dirigido
represe
ntado
criado
N
1
1
N
N
1
M
N
N
N
N
M
1
M
N
N
1
1
Filme
Categoria
Figura 2: Diagrama ER
4

4 Modelo Relacional
Após a constru¸cão do nosso desenho conceptual procedeu-se à elabora¸cão
do modelo relacional. Este modelo foi constru´ıdo tendo por base o diagrama
entidade rela¸cão e as regras para a realiza¸cão desta tarefa. Cada entidade
e cada rela¸cão irá gerar uma única tabela e após realizados os passos para
conversão do desenho conceptual no modelo relacional foi criado o modelo
relacional.
ID Título Descrição ClassificaçãoFilme
Músicas
Companhia
Escritor
Diretor
Ator
Realizador
Prémio
Lançamento
Trailer
Músicas do Filme
Representado por
Escrito por
Duração ID Companhia
ID Título Género Intérprete/Banda URL
ID Nome
Ano Tipo Descrição ID Filme
ID Título Data País ID Filme
ID Título Duração Data URL Idioma
ID Filme
ID Filme ID Música
ID Filme ID Ator
Biografia
ID Nome Foto Data de Nascimento
BiografiaID Nome Foto Data de Nascimento
ID Diretor ID Realizador
ID Filme
ID Filme ID Escritor
Categoria
Figura 3: Modelo Relacional
Para além das tabelas acima, foi criada um tabela simples - apenas com
id, username e password - que permite o utilizador registar-se e autenticar-se
na aplica¸cão. O campo password é do tipo varbinary(128).
5

5 T-SQL DDL
Após a elabora¸cão do modelo relacional procedemos à cria¸cão dos coman-
dos SQL que permitem a cria¸cão das respetivas tabelas. Usou-se a linguagem
T-SQL DDL2
onde é poss´ıvel especificar todos os atributos, chaves primárias
e estrangeiras. O exemplo seguinte ilustra a cria¸cão da tabela filmes, ator e
rela¸cão entre ator e filmes.
Exemplo código 1
1 -- TABELA FILME
2 create table gestordefilmes.filme(
3 id int NOT NULL Identity ,
4 titulo varchar (100) ,
5 descricao varchar (8000) ,
6 categoria varchar (100) ,
7 classificacao int ,
8 duracao int ,
9 idcompanhia int ,
10 iddiretor int ,
11 idrealizador int ,
12 constraint PKFID primary key (id),
13 constraint FKCID foreign key (idcompanhia)
14 references gestordefilmes.companhia(id),
15 constraint FKDID foreign key (iddiretor)
16 references gestordefilmes.diretor(id),
17 constraint FKRID foreign key (idrealizador)
18 references gestordefilmes.realizador(id));
19 -- TABELA ATOR
20 create table gestordefilmes.ator(
21 id int not null Identity ,
22 nome varchar (50),
23 urlfoto varchar (500) ,
24 datanascimento date ,
25 biografia varchar (1000) ,
26 constraint PKAID primary key (id));
27 -- TABELA REPRESENTADO POR
28 create table gestordefilmes.representadopor(
29 idfilme int not null ,
30 idator int not null ,
2
Data Definition Language
6

31 constraint PKRPFIDMID primary key (idfilme , idator),
32 constraint FKRPFID foreign key (idfilme)
33 references gestordefilmes.filme(id),
34 constraint FKAID foreign key (idator)
35 references gestordefilmes.ator(id));
5.1 Tabelas SQL
Após da inser¸cão de todas as tabelas na base de dados (SQL server)
obtivemos o seguinte diagrama de rela¸cões.
Figura 4: Diagrama relacional de tabelas
7

A tabela que permite a autentica¸cão é a seguinte:
Figura 5: Tabela para autentica¸cão dos utilizadores
Todos os identificadores de cada tabela (id’s) são auto-incrementados.
6 T-SQL DML
Outra linguagem associada ao SQL que utilizámos foi o T-SQL-DML3
.
No caso particular do nosso trabalho, usámos explicitamente esta lingua-
gem na inser¸cão de um prémio a um filme, o mesmo pode ser visto no exemplo
de código c# seguinte.
Exemplo código 2
1 string queryInsertSQLDML = INSERT INTO gestordefilmes.premio
2 (idfilme , ano , tipo , descricao)
3 VALUES(@idfilme , @ano , @tipo , @descricao );
4
5 SqlCommand insertQuery = new SqlCommand(queryInsertSQLDML , cnn);
6 insertQuery.Parameters.AddWithValue(@idfilme , p.filme_id );
7 insertQuery.Parameters.AddWithValue(@ano , p.ano);
8 insertQuery.Parameters.AddWithValue(@tipo , p.tipo );
9 insertQuery.Parameters.AddWithValue(@descricao , p.descricao );
Implicitamente o T-SQL DML é usado em Stored Procedures e User De-
fined Functions como se vai ver mais a frente.
3
Data Manipulation Language
8

7 Normaliza¸cão
Após alguns estudos, conclu´ımos que as rela¸cões da nossa base de dados
se encontram na forma BCNF, logo também podemos afirmar que satisfaz
as condi¸cões das 1º, 2ª e 3ª formas. Nas seguintes figuras são apresentadas
as normaliza¸cões das rela¸cões da nossa base de dados.
Figura 6: Normaliza¸cão de Filme, Música, Companhia e Escritor
Figura 7: Normaliza¸cão de Diretor, Ator e Realizador
9

Figura 8: Normaliza¸cão de Prémio, Lan¸camento, Trailer e Músicas Do Filme
Figura 9: Normaliza¸cão de Representado por, Escrito por e Login
10

8 Stored Procedures
Dicidiu-se usar stored procedures para criar uma camada de abstra¸cão en-
tre o modelo de dados, a sua manipula¸cão e a camada aplicacional. A adop¸cão
desta abordagem permite-nos criar de forma segura, com boa performance e
que garante a integridade dos dados, métodos para criar, modificar e apagar
modelo de dados do nosso sistema de base de dados.
Outro dos motivos foi garantir um contrato de utiliza¸cão entre o ”de-
veloper”da aplica¸cão e a utiliza¸cão do nosso modelo de dados, permitindo
assim especificar que parâmetros são necessários para realizar cada opera¸cão
e garantindo também um bom controlo de erro avisando-o com T-SQL Raise
Error quando este não estiver a cumprir o contrato.
As stored procedures ao contrário de um uso do nosso modelo de dados em
DML permite que o conjunto de instru¸cões compiladas na Stored Procedure
não tenham de ser recompiladas cada vez que o procedimento é invocado,
sendo estas, apenas compiladas na primeira vez que são executadas e depois
disso são guardadas em cache, sendo que isto permite maior rapidez no acesso
ao modelo de dados.
Sendo assim, o principal foco em todas as stored procedures que se de-
senvolveu foi procurar garantir um bom controlo de erro para a camada
aplicacional e que a cria¸cão, altera¸cão ou remo¸cão de dados do nosso modelo
de dados fosse realizada de forma consistente.
O código seguinte é um bom exemplo da abstra¸cão dada ao utilizador.
Exemplo código 3
1 GO
2 CREATE PROCEDURE gestordefilmes.sp_AddFilme (
3 @id INT = NULL OUTPUT ,
4 @titulo varchar (100) ,
5 @descricao varchar (8000) ,
6 @categoria varchar (100) ,
7 @classificacao int ,
8 @duracao int ,
9 @idcompanhia int ,
10 @iddiretor int ,
11 @idrealizador int ,
12 @Escritor AS gestordefilmes.listaEscritor READONLY ,
13 @Elenco AS gestordefilmes.listaElenco READONLY ,
14 @Banda AS gestordefilmes.listaBanda READONLY
15 )
11

16 AS
17 WITH ENCRYPTION
18 BEGIN
19 INSERT into gestordefilmes.filme VALUES (@titulo ,
20 @descricao , @categoria , @classificacao , @duracao ,
21 @idcompanhia , @iddiretor , @idrealizador );
22
23 SET @id = SCOPE_IDENTITY ();
24 insert into gestordefilmes.escritopor select @id ,
25 id from @Escritor;
26 insert into gestordefilmes.representadopor select
27 @id , id from @Elenco;
28 insert into gestordefilmes.musicasdofilme select
29 @id , id from @Banda;
30 END
31 GO
Qualquer utilizador desta base de dados, sabe que para inserir um filme
tem de chamar o Stored Procedure ”gestordefilmes.sp AddFilme”com os parâmetros
definidos, para o filme ser inserido. Assim sendo, é completamente transpa-
rente para o utilizador que, na realidade, a informa¸cão que ele introduziu
está guardada em 3 tabelas diferentes. Essa transparência e simplicidade do
lado do utilizador era um objetivo a alcan¸car na cria¸cão do nosso projeto.
O código seguinte é um exemplo da implementa¸cão de um Stored proce-
dures que permite editar os dados na base de dados.
Exemplo código 4
1 go
2 create procedure gestordefilmes.sp_EditEscritor(
3 @escritor_id int ,
4 @nome varchar (50),
5 @data date ,
6 @url varchar (500) ,
7 @bio varchar (1000)
8 )
9 as
10 WITH ENCRYPTION
11 begin
12 update gestordefilmes.escritor
13 set nome = @nome ,
14 datanascimento = @data ,
12

15 urlfoto = @url ,
16 biografia = @bio
17 where gestordefilmes.escritor.id = @escritor_id
18 end
19 go
Os Stored procedures foram também utilizados para podermos efetuar
pesquisas sobre as tabelas pretendidas pelo utilizador. Para esta situa¸cão,
pretendia-se tornar a abstra¸cão para o utilizador ainda maior, de modo a
que este pudesse pesquisar por múltiplos atributos sem que nenhum seja
obrigatório. Por esta lógica, a combina¸cão de atributos na pesquisa é sempre
um “and”.
Um exemplo de uma pesquisa implementada recorrendo a um Stored pro-
cedures pode ser visto no código seguinte.
Exemplo código 5
1 go
2 CREATE procedure gestordefilmes.sp_pesquisarPremio (
3 @IDFilme int = null ,
4 @Ano int = null
5 )
6 AS
7 WITH ENCRYPTION
8 BEGIN
9 declare @tmp table(id int , idfilme int , ano int ,
10 tipo varchar (20), descricao varchar (200));
11 declare @out table(id int , idfilme int , ano int ,
12 tipo varchar (20), descricao varchar (200));
13
14 insert into @out select * from
15 gestordefilmes.udf_GetPremios ();
16
17 if not @IDFilme is null
18 insert into @tmp select * from @out
19 where idfilme=@IDFilme;
20 else
21 insert into @tmp select * from @out;
22 delete from @out
23
24 if not @Ano is null
25 insert into @out select * from @tmp
13

26 where ano=@Ano;
27 else
28 insert into @out select * from @tmp;
29
30 delete from @tmp;
31 select idfilme ,ano ,tipo ,descricao from @out;
32 END
33 go
14

9 Views
Optámos por não utilizar views uma vez que não são compiladas, op-
timizadas e não suportam uma lógica mais complexa para uma consulta.
Consequentemente decidimos utilizar somente User Defined Funtions.
10 UDF’s
User Defined Funtions (UDF) constituem outra ferramenta utilizada para
a cria¸cão da camada de abstra¸cão, proporcionando ao utilizador os dados que
ele pede, independentemente da sua localiza¸cão nas tabelas da base de dados.
Existe uma grande semelhan¸ca entre views e UDF’s, mas estas últimas têm
a vantagem de poderem ser parametrizáveis. Mais uma vez, temos UDFs
que apenas tem um ”select * from table”mas por razões de escalabilidade e
consistência, foram utilizadas para todas as tabelas.
Exemplo código 6
1 go
2 CREATE FUNCTION gestordefilmes.udf_GetFilme () RETURNS table
3 AS
4 RETURN
5 (
6 SELECT titulo , categoria , classificacao ,
7 duracao , descricao , idcompanhia , idrealizador
8 FROM gestordefilmes.filme
9 );
10 go
Exemplo código 7
1 go
2 CREATE FUNCTION gestordefilmes.udf_GetLancamento () RETURNS table
3 AS
4 RETURN
5 (
6 SELECT pais , data , titulo
7 FROM gestordefilmes.lancamento
8 );
9 go
15

11 Índices
Com o aumento do volume de dados, os pedidos de consulta come¸cam
a ter tempos de resposta maiores, pois os dados que existem nas tabelas
encontram-se desorganizados. Para contrariar este aumento dos tempos de
resposta devemos manter as tabelas organizadas de forma a que as consultas
sejam efetuadas mais rapidamente. A utiliza¸cão de ´ındices nos campos que
mais frequentemente serão utilizados é a maneira indicada, onde um ponteiro
é criado para a posi¸cão real de cada registo.
Exemplo código 8
1 -- index da tabela filmes , colunas: titulo , categoria ,
2 -- classificacao , companhia , diretor , realizador;
3 CREATE INDEX filmeTitulo ON gestordefilmes.filme (titulo );
4 CREATE INDEX filmeCategoria ON gestordefilmes.filme (categoria );
5 CREATE INDEX filmeClassificacao ON gestordefilmes.filme
6 ( classificacao );
7 CREATE INDEX filmeCompanhia ON gestordefilmes.filme
8 ( idcompanhia );
9 CREATE INDEX filmeDiretor ON gestordefilmes.filme (iddiretor );
10 CREATE INDEX filmeRealizador ON gestordefilmes.filme
11 (idrealizador );
Exemplo código 9
1 -- index da tabela realizador , colunas: nome;
2 CREATE INDEX realizadorNome ON gestordefilmes.realizador (nome );
3
4 -- index da tabela premio , colunas: filme , ano , tipo;
5 CREATE INDEX premioFilme ON gestordefilmes.premio (idfilme );
6 CREATE INDEX premioAno ON gestordefilmes.premio (ano);
7 CREATE INDEX premioTipo ON gestordefilmes.premio (tipo );
16

12 Triggers
Os triggers, tanto nesta base de dados para gestão e organiza¸cão de filmes
como em qualquer outra, são utilizados para restringir ou impedir o acesso
a tabelas por users sem acesso para tal. Eles impedem que, por exemplo,
aplica¸cões que só possuem permissões de leitura possam inserir ou apagar
dados e inserir tabelas inteiras, por exemplo.
Atualmente a nossa base de dados contem triggers a impedir o delete de
todas as tabelas. Idealmente, haveria mudan¸cas a implementar nos triggers,
como impedir a inser¸cão ou update em qualquer tabela e/ou nos Stored
Procedures, que executam essas fun¸cões de desativá-los no in´ıcio e ativá-los
de volta no final. Desta forma todo o acesso à base de dados seria controlado
através dos Stored Procedures, aumentando assim a seguran¸ca e impedindo
poss´ıveis inconsistências provocadas por utilizadores.
Os exemplos seguintes ilustram a nossa implementa¸cão de triggers.
Exemplo código 10
1
2 -- trigger delete ator
3 GO
4 CREATE TRIGGER gestordefilmes.t_removerAtor ON
5 gestordefilmes.ator
6 INSTEAD OF DELETE
7 AS
8 PRINT Operacao para eliminar ator nao e permitida !;
9 GO
Exemplo código 11
1
2
3 -- trigger delete filme
4 GO
5 CREATE TRIGGER gestordefilmes.t_removerFilme ON
6 gestordefilmes.filme
7 INSTEAD OF DELETE
8 AS
9 PRINT Operacao para eliminar Filme nao e permitida !;
10 GO
17

13 Seguran¸ca
De modo a que fosse poss´ıvel implementar um módulo de seguran¸ca,
decidimos que este podia ser aplicado num sistema de login. Para tal, e
como referido anteriormente, criámos uma tabela onde fosse possivel guardar
o username e a password.
Tal como pode ser visto no exemplo seguinte, foi criado um stored pro-
cedure que permite efetuar o registo de um novo utilizador, deste modo per-
mitindo um refor¸co da seguran¸ca.
Exemplo código 12
1 -- ADICIONAR NOVO UTILIZADOR
2 go
3 create procedure gestordefilmes.sp_AddNewUser (
4 @username varchar (50),
5 @pass varchar (128)
6 )
7 as
8 begin
9 insert into gestordefilmes.login values (@username ,
10 EncryptByPassPhrase('poy5t523dsz2s23zaw4 ', @pass ))
11 end
12 go
O código seguinte permite fazer a valida¸cão das credencias inseridas.
Exemplo código 13
1 -- VERIFICAR LOGIN
2 go
3 CREATE FUNCTION gestordefilmes.udf_VerifyLogin (@username
varchar (20), @pass varchar (200)) RETURNS table
4 AS
5 RETURN
6 (SELECT DISTINCT idUser
7 FROM gestordefilmes.login
8 where gestordefilmes.login.username=@username
9 and convert(varchar (10), DECRYPTBYPASSPHRASE
10 ('poy5t523dsz2s23zaw4 ',
11 gestordefilmes.login.pass )) = @pass );
12 go
18

14 Interface gráfica
Nesta seçcão iremos apresentar um pouco da interface que o utilizador
poderá encontrar ao aceder à nossa aplica¸cão.
Figura 10: Interface para o processo de login do utilizador
Figura 11: Interface para o processo de registo do utilizador
Figura 12: Interface inicial com icons ilustrativos de cada tarefa
19

Figura 13: Interface para o processo de adi¸cão. Nesta caso, adi¸cão de um
filme
Figura 14: Interface para o processo de adi¸cão. Nesta caso, adi¸cão de um
ator
20

Figura 15: Interface para o processo de edi¸cão. Nesta caso, edi¸cão de um
ator
Figura 16: Interface para o processo de edi¸cão. Nesta caso, edi¸cão de um
realizador
21

Figura 17: Interface para o processo de pesquisa. Nesta caso, pesquisa de
um ﬁlme
Figura 18: Interface para o processo de pesquisa. Nesta caso, pesquisa de
um ator
14.1 Demo - V´ıdeo
https://www.youtube.com/watch?v=yJHNKVBkXI0
22

15 Reposit´orio
https://github.com/ruipoliveira/gestorfilmesBDIHC
Pastas para o trabalho de Base de Dados:
• GestorDeFilmesWPF
• SQLs
23

16 Conclusão
Chegado ao final deste relatório, é nossa inten¸cão efetuar uma retrospetiva
da evolu¸cão do mesmo, tendo em conta os problemas com que nos deparámos,
e principais conclusões retiradas.
A nossa aplica¸cão - ’Gestor de Filmes’ - permitiu-nos aplicar os conheci-
mentos adquiridos ao longo das aulas teóricas e práticas da unidade curricular
de Base de Dados.
Apesar do projeto referido apresentar todas as funcionalidades indis-
pensáveis para uma base de dados do tipo, havia mais funcionalidades que
não foram implementadas por falta de tempo, entre as quais destacamos:
cria¸cão de novos triggers com funcionalidades diferentes das existentes; existências
de novas formas de filtrar a informa¸cão;
Em rela¸cão à parte de interface faltou-nos a visualiza¸cão das fotos/v´ıdeos
(URL) dos atores, escritores, diretores e trailers/músicas.
Concluindo, foi um trabalho bastante útil para o nosso desenvolvimento
enquanto estudantes da área de Engenharia de Computadores e Telemática,
pois permitiu a prática dos conceitos adquiridos na disciplina de Base de
Dados.
17 Referências
• http://www.flaticon.com/packs/linear-color-web-interface-elements/
• Slides das aulas teóricas da disciplina de Base de Dados - edi¸cão 2016
• Guiões práticos da disciplina de Base de Dados - edi¸cão 2016
18 Anexos
Em anexo a este relatório anexou-se uma pasta com todos os SQL usados
para este sistema.
24

Gestor de Filmes - Relatório Prático

Mais conteúdo relacionado

Semelhante a Gestor de Filmes - Relatório Prático

Mais de Rui Oliveira

Gestor de Filmes - Relatório Prático