Normalizar Tabelas

daquinho · 31 de janeiro de 2017

Olá pessoal,

já fui mais safo, mas a muito tempo não estudo programação e falta de tempo, normal.

tenho um banco que estou sismado de que tá faltando coisas e outras tenho certeza.

no banco tem uma determinada tabela.

Columns:
idusuario_evento int(11) AI PK
idevento int(11) FK
idusuario int(11) FK
lista_convidados text
campanha text
data_limitedatetime

essa tabela é resultado de muito para muito de outras duas tabelas e devo cadastrar uma lista de convidados a coluna "lista_convidados" , aqui eu coloquei como uma lista, pensei que, cada linha, um convidado, para normalizar melhor, deveria criar uma nova tabela?

----------------------------------------------------------------------------------------------------------

esses eventos podem ter mais de um dia, sejam dias corridos ou não e devo contar com a possibilidade de que em cada dia de evento, um prazo limite( normalmente horas antes do evento) para editar a lista de convidados, devo criar uma nova tabela só para poder criar essas datas de evento e data prazo?

vlw a quem puder ajuda.

wmsilva191 · 1 de fevereiro de 2017

Muitos para Muitos = Nova tabela

Se puder veja essa documentação que fiz, espero não te confundir;

http://wms.eti.br/index.php/documentacao/banco-de-dados/pratica/modelando-um-sistema-de-manutencao

[CONVIDADO]

codigoconvidado

nome

etc

[EVENTO]

codigoevento

local

data

etc

[CONVIDADOS]

codigoconvidado

codigoevento

daquinho · 1 de fevereiro de 2017

agora relendo, vejo q posso melhorar a questão e assim uma resposta, pois não entendi bem as tabelas que escreveu....

existem as tabelas usuario e evento que são * para * e resultaram na tabela descrita acima, que é a tabela usuario_evento.

dentro de "usuario_evento eu tenho que fazer uma lista de convidados , essa coluna para me simplificar , fiz do tipo "text" e cada linha seria um convidado, acho que não é o ideia, to certo?

na tabela "usuario_evento" tenho um campo de texto que é para descrever os dias e horários dos eventos, acredito que uma forma mais elegante seria que, cadastrado o evento, cadastrar separadamente cada dia com sua respectiva hora, como fazer? Exemplo, uma apresentação nessa semana, será exibida em 3 dias diferentes, sexta, sábado e domingo, sendo domingo numa hora diferente, como deveria fazer?

existem administradores que irão cadastrar os eventos e informar que colaboradores podem adicionar convidados, como limitar o acesso do colaboradores?

espero n estar pedindo muito, rs. camarada, vlw pela a atenção

DiF · 1 de fevereiro de 2017

Pelo que entendi,

Você pode ter uma tabela de usuários somente para o cadastro dos usuários. Uma tabela de eventos, somente para cadastro de eventos(local, hora, inicio fim, tempo e etc LIMITE de convidados)

Uma tabela de administradores.

Tendo estas 3 tabelas, você faz uma outra N:N onde usa-se somente campos do tipo INT para foreing key(chave estrangeira)

Nesta tabela N:N é só para relacionar QUE evento, promovido por TAL administrador, que terão os SEGUINTES convidados.

Então seria algo como isto:

usuarios

ID usuario   email               senha
1   Fulano   [email protected]   fulano123 
2   Beltrano [email protected]   beltrano2

Administradores

ID  admin     email                 senha 
1   Ciclano   [email protected]   ciclano123

Eventos

ID  evento          ID_admin  limite_convidados dataHora            
1   Formatura 2017  1         50                2017-02-01 20:30:00 
2   Recepção ADS    1         10                2017-04-02 17:00:00

Tabela N:N entre usuários e eventos que podemos chamar de usuarios_convidados

ID   id_evento  id_usuarios
1      1           1
2      1           3
3      1           48
4      1           9  
5      2           6
6      2           1
7      2           3

Veja as tabelas.

No usuários temos uma tabela que recebe os dados de usuários os que serão convidados.

No administradores, temos uma tabela que recebe os dados dos administradores, os que vão organizar e cadastrar o evento

No eventos, temos uma tabela que recebe o nome do evento(campo do tipo Varchar), o ID de qual admin registrou(campo do tipo INT chave estrangeira), o número de limite de convidados(campo do tipo INT) e a data com hora. Este campo é do tipo datetime.

No usuarios_convidados, temos uma tabela que recebe o ID do tipo INT chave estrangeira do evento e o ID do convidado(usuario) do tipo INT também chave estrangeira.

PS: em todas as tabelas o campo "ID" o primeiro, é um campo do tipo INT chave primária com auto increment.

Lembre-se de que para que tudo funcione corretamente, suas tabelas DEVEM ser do tipo "innoDB" na tabela que será referenciada, deve conter o INDEX ou seja, o índice do campo na qual você vai referenciar, que no caso são as chaves estrangeiras.

é por aí a coisa. mais do que isso estaríamos dando pronto o seu exercício

Creio que você pode dar uma estudada novamente em modelagem de banco de dados e ler sobre as 1 NF e 2 NF

adicionado 3 minutos depois

PS2: Perceba que na tabela N:N o id_evento possui várias linhas com o mesmo ID assim como id_usuario 1 e 3 se repete.

Isso mostra que o usuário 1 e 3 ambos participarão do evento 1 e evento 2.

daquinho · 2 de fevereiro de 2017

entre um colaborador e um administrador, a diferença é apenas poder criar o evento, achei que ficaria "mais correto" não distinguir, apenas um campo descrevendo o tipo de usuário. OK vou separar.

------------------------

Citação

No eventos, temos uma tabela que recebe o nome do evento(campo do tipo Varchar), o ID de qual admin registrou(campo do tipo INT chave estrangeira), o número de limite de convidados(campo do tipo INT) e a data com hora. Este campo é do tipo datetime

um mesmo evento(cada tupla no bd) pode ter várias datas, devo separar em outra tabela essas datas?

------------------------

Citação

No usuarios_convidados, temos uma tabela que recebe o ID do tipo INT chave estrangeira do evento e o ID do convidado(usuario) do tipo INT também chave estrangeira.

Não existe usuário convidado, os usuários do sistema, adm e colaboradores, cadastram os convidados, esses sõ me interessam seus nomes para lista de presença, então cada nome cadastrado é um convite. Por isso pensei em um campo do tipo texto e cada linha seria um convidado, mas pensei que seria "mais correto" no BD, criar uma tabela só p essa lista, estou certo?

------------------------

vlw a ajuda.

DiF · 2 de fevereiro de 2017

@daquinho

Vamos lá...

2 minutos atrás, daquinho disse:

entre um colaborador e um administrador, a diferença é apenas poder criar o evento, achei que ficaria "mais correto" não distinguir, apenas um campo descrevendo o tipo de usuário. OK vou separar.

Dependendo do objetivo pode ter diferença sim.

Por exemplo o administrador pode ter acesso aos dados dos eventos onde ele pode excluir um convidado, alterar data e hora de um evento e etc.

O colaborador, teria só a permissão de criar eventos e inscrever convidados, ou contribuir com alguma coisa seja financeiramente ou doações( para a promoção do evento) Esta seriam as diferenças.

Mas se você não quiser separa-los, onde o administrador e o colaborador são iguais, você pode tornar o nome do campo como "promoter" onde o admin e o colaborador ambos fariam o mesmo papel.

Eu particularmente acho mais interessante separar as funções. Mas não há necessidade de criar uma tabela para cada um. pode ser na mesma.

7 minutos atrás, daquinho disse:

um mesmo evento(cada tupla no bd) pode ter várias datas, devo separar em outra tabela essas datas?

Não precisa. Se tem uma tabela eventos, basta que ambos eventos(iguais com datas diferentes) sejam um registro diferente.

8 minutos atrás, daquinho disse:

Não existe usuário convidado, os usuários do sistema, adm e colaboradores, cadastram os convidados, esses sõ me interessam seus nomes para lista de presença, então cada nome cadastrado é um convite. Por isso pensei em um campo do tipo texto e cada linha seria um convidado, mas pensei que seria "mais correto" no BD, criar uma tabela só p essa lista, estou certo?

Nesse caso, então não pode ser uma tabela de muitos para muitos " N:N" pois nela jamais deve-se colocar dados em texto. Geralmente o N:N é para registrar campos de chave estrangeiras que se relacionam em 2 ou mais tabelas.

Então, aí você não faz esse N:N mas sim cria uma tabela para receber o nome da pessoa no tipo varchar e não text. Inclusive pode até usar o mesmo exemplo ali da ultima tabela.. mas só trocando o campo ID_usuario, por "convidados"

ID   id_evento  convidados
1      1           Fulano
2      1           Beltrano
3      1           Pedicrano
4      1           Sharano  
5      2           Biro Biro
6      2           Zina
7      2           Chalita

Esta tabela não é um N:N mas atende o que você deseja. onde ele recebe somente o ID chave estrangeira do evento e um campo varchar para nomes.

No mysql e outros bancos de dados, os campos de texto, geralmente são usados VARCHAR. Existe o tipo text, longtext e mediumtext. Estes só devem ser usados quando há um volume muito grande de dados no mesmo campo. por exemplo conteúdo de um artigo.

Para nomes, e coisas pequenas, deve-se usar VARCHAR