Sou um estudante que aprendeu sobre banco de dados teoricamente, não na prática.
Mas agora tenho a chance de projetar um banco de dados enquanto faço esse pequeno projeto de brinquedo em equipe.
Aqui está um diagrama (omitido 1:1, 1:n, n:m) conforme abaixo:
E aqui está a descrição sobre tabelas:
- Teatro
Esta tabela contém informações sobre teatro. Um teatro pode ter muitos espetáculos.
- Assento
Esta tabela contém informações sobre assento.
O assento pode ser diferenciado pelo par de chaves primárias: (theater_no, seat_no)
- Mostrar
Esta tabela contém informações sobre show.
Um teatro pode ter muitos espetáculos. Mas o espetáculo acontecerá em apenas um teatro.
(Portanto, o Teatro depende do Show. Podemos escolher o Teatro adequado automaticamente após selecionar Show.)
- assento_show_grade
Esta tabela contém classificações de assento para cada assento. Esta é uma tabela de mapeamento entre 'assento' e 'show' porque um mesmo assento pode ter graus diferentes para shows diferentes.
[Aqui está um exemplo : ]
'Show 1', 'Show 2' acontecem no mesmo Teatro, 'Teatro 1' e 'Teatro 1' têm 'Assento 1'
Então, 'Assento 1' é grau A para 'Show 1' e 'Assento 1' é grau C para 'Show 2'.
- Usuários
Esta tabela contém informações sobre o usuário.
- avaliações
Esta tabela contém informações sobre avaliações.
- revisão_assento
Esta tabela contém informações sobre avaliações de assentos.
- mostrar_revisão
Esta tabela contém informações sobre avaliações do show.
Lógica de serviço:
Aplicativo de logins de usuário, uma lista de páginas principal é exibida.
Se o usuário selecionar um show, lista a sede do teatro (onde o show escolhido aconteceu).
Se o usuário selecionar um assento, será exibida uma avaliação sobre o assento (mas a avaliação também depende do show).
O '3' é um problema principal para mim, porque é difícil projetar uma tabela de 'avaliações', pois depende não apenas do show, mas também do assento.
No início, projetei a tabela 'reviews' com 4 chaves primárias: (user_id, show_no, theater_no, seat_no) sem a tabela 'seat_review' e a tabela 'show_review'.
Mas achei que isso era muito confuso, então mudei o design como acima.
Ainda estou confuso sobre esse design, não tenho certeza se isso preservará a integridade dos dados, a velocidade de processamento, etc.
Então, minha principal dúvida é:
Existe alguma boa ideia para criar uma mesa de 'revisão'? (parece (muitos-para-muitos)-para-muitos (?) para mim.)
Para as 4 tabelas da esquerda ('theater', 'seat', 'seat_show_grade', 'show') tem relação cíclica. Esse design é ruim para banco de dados? Se estiver ruim, como posso mudar isso?
Obrigado pela ajuda.
Anexado:
A ideia anterior de usar tabela de mapeamento.
(O que eu disse são 4 chaves primárias, sem 'seat_review' e 'show_review')
A
seat_reviewtabela que você mostra não é muitos para muitos para muitos. Está simplesmente representando um relacionamento muitos-para-muitos entrereviewseseat.Pode parecer assim porque tem três colunas, mas uma das tabelas a que faz referência tem uma chave primária composta, portanto a chave estrangeira que faz referência a essa chave primária também deve ter múltiplas colunas.
Você tem um segundo relacionamento muitos-para-muitos entre
reviewseshow. Isso é independente do primeiro relacionamento muitos-para-muitos entrereviewseseat.Tentar combinar relacionamentos muitos-para-muitos independentes em uma única tabela de interseção é uma violação da 4ª Forma Normal. Não faça isso! Causa mais problemas do que salva.
Acho que você quer dizer as 4 mesas certas. Pelo menos, essas quatro tabelas estão à direita quando olho para o seu diagrama.
Eles não têm um relacionamento cíclico.
seat_show_gradereferênciasseateshowseatreferênciastheatershowreferênciastheaterNão há referência a
theaternenhuma das outras tabelas. Portanto, não há ciclo.Escute, tenho trabalhado em uma empresa que presta serviços para cinemas de todo o mundo e seu design está errado.
Você deve ter um esquema em estrela como este:
No centro do esquema em estrela deve haver uma tabela chamada Ticket ou Transação porque todo o seu negócio gira em torno dela. Não assentos ou shows.
Além disso, você está criando loops voluntariamente: vê como suas dimensões estão criando círculos? Isso causará bloqueios e impasses em todos os lugares. Esta é uma abordagem errada: essas tabelas não deveriam estar vinculadas entre si, mas deveriam estar diretamente vinculadas a uma tabela de fatos ( Ticket ou Transaction ).