Projeto de Base de Dados – Relatório

Nome da Base de Dados: Bleach

Integrante(s) do grupo: Miguel António Dantas, up201706939.
Baseado no Universo de: Bleach (Manga), escrito por Tite Kubo.

No projeto estão incluidos os ficheiros:

Projeto_BD_1920.pdf -> O próprio.
Modelo ER(Done).er -> Código para o modelo ER através do dbdia.
Bleach_ER Model.png -> O modelo ER da Base de Dados.
Modelo Relacional.sch -> Código para o modelo relacional através do dbdia.
Bleach_Rel Model.png -> O modelo Relacional da Base de Dados.
Bleach_BD(SQL).sql -> A BD pedida em SQL.

Requisitos para a Base de Dados:

Consideremos o universo de Bleach em que temos as seguintes entidades-tipo,
respetivos atributos e relacionamentos:
• CHARACTER com os seguintes atributos: Número incrementado para organização e
optimização, Nome único, Raça multi-valor, Sexo, Rank opcional, Local de
nascimento, estado [se se encontra vivo(‘A’ for Alive) ou morto(‘D’ for Dead)],
personagem tem uma arma opcional, várias personagens podem usar várias
técnicas de Kidou (opcional), várias pessoas podem obedecer a uma pessoa
(opcional) e todos os personagens vivem numa cidade.
• WEAPON com Nome único, cada arma é de um tipo específico, armas têm potêncial
para ter mais que uma forma, assim sendo, a 1ª forma é o mesmo que o nome
previamente referido sendo assim este parametro derivado, finalmente, a arma
poderá ter uma 2ª forma (opcional), todas as armas pertencem a alguém e todas
elas foram forjadas algures.
• LOCATION: Cada cidade tem um nome único, há vários Mundos à qual a cidade pode
pertencer, a cidade é governada por alguém opcional, Multi-valor de forças
militares, uma arma pode ter sido forjada numa cidade, mas não ouve
necessariamente armas forjadas em todas as cidades, não há gente a viver em todas
as cidades e técnicas de kidou não se aprendem em todo o lado.
• KIDOU: Cada técnica tem um nome específico e único, um nível que indica o grau de
dificuldade de realizar a técnica (de 1-99) bem como o seu poder, cada kidou tem
 um tipo como Hado (ofensivo), Bakudo (protectivo) e ainda Kaido (Cura) - embora
seja de notar que não é específicada nenhuma forma da última fazendo com que
este tipo tenha sido por consequência excluído da BD – todas formas de Kidou
podem ser aprendidas numa cidade, mas não necessariamente em todas, algumas
técnicas de Kidou são confirmadas ser utilizadas por alguns personagens.

Tradução dos requisitos para o modelo ER

• CHARACTER: Num (Chave Primária criada para otimização previamente), Name
(Atributo único do Nome), Race (Multi-valor), Sex (‘M’ or ‘F’), Rank (Opcional),
Birth_Location, State (‘D’ or ‘A’).
• WEAPON: Name (Chave Primária, pois é o atributo único), Type, Atributo Composto
Release ( Name1st (Derivado), Name2nd (Opcional)),
• LOCATION: Name (Chave Primária, atributo único), World, Ruler (Opcional), Military
(Multi-valor).
• KIDOU: Name (Chave Primária, atributo único), Level, Type.

• HAS: Como cada personagem tem uma arma e cada uma das armas é única para
cada personagem, mas nem todos os personagens têm uma arma, e já nem todas
as armas têm dono, então esta será uma relação de 1:1, parcial do lado CHARACTER
e do lado WEAPON.
• OBEYS_TO: Vários personagens podem obedecer a um, mas nem todos obedecem
a alguém, assim como há quem não tenha quem lhe obedeça, assim dá-se uma
relação de N:1, dentro da própria entidade CHARACTER de caráter parcial.
• FORGED_IN: Todas as armas são forjadas numas poucas cidades, fazendo com que
a relação fique N:1, em que N é total e fica do lado de WEAPON, 1, por outro lado,
é parcial e fica do lado de CITY.
• LEARNED_IN: O mesmo caso que FORGED_IN, todas as técnicas aprendidas são em
poucas cidades, assim a relação é N:1, em que N é total e fica do lado de KIDOU, o
1, por sua vez, é parcial e fica do lado de CITY.
• USES: Como uma parte dos personagens sabe usar técnicas de Kidou (Demonic Arts),
mas não todas, então estamos perante uma situação de M:N parcial de CHARACTER
para KIDOU.
• LIVES_IN: Como todos os personagens vivem em cidades, com vários personagens
por cidade, mas nem todos vivem em todas as cidades mencionadas (em apenas
algumas delas), então temos que N:1, com N completo do lado de CHARACTER e 1
parcial do lado de CITY.

Nota: Para personagens mortos a relação de LIVES_IN refere-se ao sítio onde estes morreram.
Tradução do modelo ER para o Relacional
• RACE: Antes o Atributo multi-valor Race que, precisamente por ser multi-valor,
passa-se para a sua própria tabela de forma a que possa ser multi-valor
efetivamente. Assim, chama-se nesta tabela o próprio atributo como chave primária
e ainda se tem a chave externa que irá efetivamente conectar os valores ao
respetivo, neste caso, Char_Num está a apontar para Num de forma a que se saiba
a quem estão a ser atribuídos os “VALUES” atribuidos a Race. O mesmo se verifica
na passagem do multi-valor Military para a tabela MILITARY.
• CHARACTER: “Perde” o atributo Race, mantendo todos os outros atribtos originais.
Foi adicionado um atributo chave externa Obeys_To que é opcional, isto ocorre pois
a relação OBEYS_TO era interna e de carater parcial, levando a essa possibilidade.
Adicionado também foi a chave externa Weapon_Name, também opcional, uma vez
que a relação HAS é de cardinalidade 1:1 e é parcial de ambos os lados, e finalmente,
também foi adicionada a chave externa City_Name visto que a relação LIVES_IN tem
uma cardinalidade N:1 na qual o lado N tem participação total.
• WEAPON: Colapsa-se o atributo composto resultando nos novos atributos:
RName1st e RName2nd. De seguida, desparece o atributo RName1st, por ser
atributo derivado de Name, RName2nd mantém-se opcional; Os atributos restantes
mantém-se (Name e Type). Adiciona-se o atributo chave externa City_Name, pois
verifica-se a mesma situação que com o LIVES_IN, ou seja, cardinalidade N:1 em que
o lado de N é total.
• CITY: Retira-se o Multi-valor Military, mantendo o resto dos atributos da entidade
CITY iguais.
• KIDOU: Mantêm-se todos os atributos base: Name (Chave Primária), Level e Type.
Também é adicionada pela propriedade de que a relação LEARNED_IN apresenta
cardinalidade N:1 com participação total de N, que, neste caso era do lado de
KIDOU, assim se obtém mais um atributo chave externa da chave primária da tabela
City(Name): City_Name.
• USES: A criação desta tabela deve-se ao facto de a entidade CHARACTER e a entidade
KIDOU estarem relacionadas entre si com cardinalidade M:N. Isto leva à criação
também dos seus atributos, os quais chaves externas para as principais das
entidades envolvidas, ou seja, Char_Num como chave principal externa para a chave
principal de CHARACTER – Num e Kidou_Name como chave principal externa da
chave principal de KIDOU – Name.