• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

bergonzzi

Problema na organização de dados

20 mensagens neste tópico

Ois pessoal,

Gostava que alguém mais experiente em bases de dados me desse umas dicas sobre como organizar uns dados em tabelas.

Contextualizando.. tenho uma tabela "PARQUES" com vários campos que descrevem os detalhes de parques de campismo (nome, morada, telefone, etc.).

A questão é que cada parque de campismo tem também uma tabela de preços. E aqui se coloca o problema, como é que eu hei-de enfiar uma tabela de preços num record referente a um parque?

Mais.. a tabela de preços tem um número fixo de colunas (são 9) mas as rows já não são fixas, podendo ser apenas uma ou cerca de 16 no máximo. Para tornar as coisas ainda mais difíceis, enquanto que os headers das colunas têm nomes ou labels fixos (nem precisam de estar na BD), as rows têm nomes dinâmicos, ou seja dependem do parque em questão.

Só para ilustrar a tabela de preços..

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

época  | criança | adulto | tenda

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

alta  |        |        |

baixa  |        |        |

natal  |        |        |

páscoa |        |        |

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

As colunas são sempre essas (na realidade são mais mas é só para simplificar). As linhas é que, em alguns parques só há uma época, noutros há estas todas, e noutros há mais ainda.

Resumindo, qual será a melhor maneira de fazer com que cada record na tabela PARQUES tenha associado uma tabela de preços semelhante a esta..?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Assim como estas a propôr o teu problema não consigo saber practicamente grande coisa, mas para aquilo que precibi é o seguinte:

tens que utilizar um campo identificatifo da tabela Parques (ou seja, uma chave primaria que definiste) nesta dos preços.

Se faltar mais alguma coisa não sei porque não tenho mais elementos.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Se calhar não fui claro..

As chaves primárias e as relações entre as tabelas já está tudo definido, mas a questão aqui é outra.

O que se passa é que cada parque de campismo (= 1 record na tabela PARQUES) tem uma tabela de preços.

Esquecendo agora as particularidades dessa tabela de preços, a minha dúvida é: qual a melhor maneira de colocar uma tabela de preços para cada parque, seja na mesma tabela, seja numa tabela separada. No fundo a minha dúvida é como representar uma tabela dentro de uma tabela.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Pões tudo relacionado com os preço numa única tabela depois quando quizeres obter os resultados de um terminado parque é só usares os filtros.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Eu não sou nenhum mestre em Bases de Dados, na verdade toda a minha experiencia se resume a uma cadeira da faculdade mas...

Na minha opinião o que tu precisas é de criar mais duas tabelas, uma tabela com as epocas e uma tabela com os precos. Assim cada preço fica associado a uma época e a um parque de campismo.

Acho que resolve o teu problema.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

A melhor solução é teres uma tabela de preços ligada com uma foreign key (FK, aka chave estrangeira) que liga à primary key chave (PK, aka chave primária).

Cada registo na tabela Parques terá "n" registos na tabela de preços, ou seja, cada parque pode ter vários preços-

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

SacoPlastico, acho que isso até era capaz de resultar mas não sei se não se iria tornar complexo demais quando fosse pra fazer querys..

M6, o prob. é que como podes ver na tabela de exemplo em baixo, as épocas que estão na primeira coluna, variam de parque para parque.

E depois.. tou aqui a imaginar como seria o interface para inserir estes dados no CMS..! Dá vontade de meter as tabelas em excel e mandar o gajo ler on-the-fly..  :)

Vejam lá um exemplo duma das tabelas mais preenchidas que pode vai existir:

tabpreoshv8.gif

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

As queries não ficam nada muito complexas... assim até tens a opção de só sacar os preços de uma determinada época.

Ou então podes fazer uma pequena modificação e em vez de teres uma tabela para as épocas incluis a época numa coluna da tabela de preços tal como disse o M6. Só acho a minha opção mais apropriada no sentido de garantires uma melhor homogeneidade na denominação das épocas...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

As queries não ficam nada muito complexas... assim até tens a opção de só sacar os preços de uma determinada época.

Exacto. As nossas opiniões convergem e são a solução correcta para este problema.

Ou então podes fazer uma pequena modificação e em vez de teres uma tabela para as épocas incluis a época numa coluna da tabela de preços tal como disse o M6. Só acho a minha opção mais apropriada no sentido de garantires uma melhor homogeneidade na denominação das épocas...

Também concordo. A separação por épocas é a abordagem que melhor resolve este problema.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Acho que já estou a entender um bocado melhor, seria muito abusador se vos pedisse um peq. esquema das tabelas como vcs estão a dizer?

Agradeço imenso a ajuda! :biggrin:

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

ora bem, tendo em conta os dados que tens vindo a apresentar seria qualquer coisa do genero... (agora não me peças é codigo SQL)

PARQUES

ID

nome

(...)

EPOCAS

ID

nome

(...)

PRECOS

ID

ID_parque (que liga esta tabela à tabela parques)

ID_epoca (que liga esta tabela à tabela epocas)

ADULTO

CRIANCA

TENDAP.

TENDAG.

ROULOTTE

CARAVANA

CARRO

MOTA

quanto a chaves primárias seriam os ID de cada tabela, claro está, e nunca percebi bem o conceito de chave estrangeira, mas provavelmente ID_parque e ID_epoca da tabela PRECOS podem ser chaves estrangeiras...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Ahhhhhhh ta bem, agora ficou bem mais claro!  B)

Chave estrangeira é uma chave não primária numa tabela que corresponde à chave primária noutra tabela.

Já agora.. será que a tabela EPOCAS não deveria estar também ligada à tabela PARQUES, ficando assim:

EPOCAS

-----------

ID (PK)

ID_parque (FK)

nome

(...)

Isto por causa da tal questão: cada parque tem sempre épocas diferentes. Quer dizer, por vezes podem coincidir mas para "normalizar" a estrutura é melhor partir do princípio que é sempre diferente. Só que assim isto também pode levar a records duplicados na tabela épocas, nos casos em que muitos parques têm por ex. uma única época..

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

ora bem, tendo em conta os dados que tens vindo a apresentar seria qualquer coisa do genero... (agora não me peças é codigo SQL)

PARQUES

ID

nome

(...)

EPOCAS

ID

nome

(...)

PRECOS

ID

ID_parque (que liga esta tabela à tabela parques)

ID_epoca (que liga esta tabela à tabela epocas)

ADULTO

CRIANCA

TENDAP.

TENDAG.

ROULOTTE

CARAVANA

CARRO

MOTA

quanto a chaves primárias seriam os ID de cada tabela, claro está, e nunca percebi bem o conceito de chave estrangeira, mas provavelmente ID_parque e ID_epoca da tabela PRECOS podem ser chaves estrangeiras...

Não podem, são.

A chave estrangeira não é mais do que um apontador de um registo de uma tabela para a chave de outro registo de outra tabela.

A tabela de preços pode ainda ser generalizada para flexibilizar o tipo de pessoa/equipamento, ou seja, havendo outra tabela onde se colocasse essa informação, permitiria uma gestão por parte do utilizador, tornando a aplicação mais flexivel.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Ahhhhhhh ta bem, agora ficou bem mais claro!  B)

Chave estrangeira é uma chave não primária numa tabela que corresponde à chave primária noutra tabela.

Não obrigatoriamente, uma chave estrangeira pode pertencer à chave primária de uma tabela.

Já agora.. será que a tabela EPOCAS não deveria estar também ligada à tabela PARQUES, ficando assim:

EPOCAS

-----------

ID (PK)

ID_parque (FK)

nome

(...)

Isto por causa da tal questão: cada parque tem sempre épocas diferentes. Quer dizer, por vezes podem coincidir mas para "normalizar" a estrutura é melhor partir do princípio que é sempre diferente. Só que assim isto também pode levar a records duplicados na tabela épocas, nos casos em que muitos parques têm por ex. uma única época..

Não é necessário. A estrutura está normalizada. A combinação ID_parque e ID_epoca na tabela PRECOS quer dizer que um determinado parque numa determinada época tem um determinado conjunto de preços.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Pessoal, acho que depois já não chateio mais, mas desde já obrigado pq me ajudaram bastante.  B)

Queria só que dessem uma última olhadela nas relações, vou fazer a BD em access primeiro para fazer umas experiências e ver se funciona tudo bem, depois reproduzo em MySql:

relationshipscampismogq5.th.jpg

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Acho que falta alguma coisa em relação dos parques, imaginando que pões esta base de dados numa página web ou mesmo no programa só destinado a parques.

1 - Como é que vais dizer que um determinado parque já tem as reservas todas feitas ou ainda falta reservar uma ou algumas áreas para ser reservadas.

2 - Falta ainda dizer que fora daquele determinado tempo de duração o parque está disponivel para futuras ocupações

Nota: Se ainda faltar alguma coisa, neste momento me está a escapar.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Acho que falta alguma coisa em relação dos parques, imaginando que pões esta base de dados numa página web ou mesmo no programa só destinado a parques.

1 - Como é que vais dizer que um determinado parque já tem as reservas todas feitas ou ainda falta reservar uma ou algumas áreas para ser reservadas.

2 - Falta ainda dizer que fora daquele determinado tempo de duração o parque está disponivel para futuras ocupações

Nota: Se ainda faltar alguma coisa, neste momento me está a escapar.

Isto é para um site, mas atenção que não irá ter reservas! O objectivo é criar na net um site agradável e fácil que reúna todos ou quase todos os parques de campismo de uma forma organizada e que permita aos utilizadores não só consultar os dados/fotos dos mesmos mas também deixar reviews e classificações.

Tive também uma ideia quer era capaz de ser interessante.. para mostrar o mapa do local do parque, em vez de mostrar em imagem fixa, pensei que talvez desse para utilizar o API do google maps e mostrar uma mapa dinâmico. Tenho as coordenadas de GPS (em formato DMS) de cada parque, é só converter em decimal e tentar chamar o mapa. Já alguém fez isto?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Quanto ao modelo de dados apresentado:

- a tabela "reviews só necessita do campo id se um utilizador puder fazer mais de uma review para cada parque, caso contrário o campo está a mais;

- a tabela "precos" tem a mesma nota acima;

- a tabela "epocas" talvez devesse ter um nome ou descrição e não só um intervalo de tempo, para se poder ter algo do género, "Primavera-Verão 2006"

- os contactos da tabela "parques", estando OK, poderiam estar numa tabela à parte, havendo depois tipos de contactos e contactos, como disse tal como está está correcto, mas a gestão dos contactos é muitas vezes feita "à parte", depende também das necessidades, por exemplo, um parque pode ter 3 fax e outro pode não ter nenhum.

De resto, o modelo parece OK. :D

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Quanto ao modelo de dados apresentado:

- a tabela "reviews só necessita do campo id se um utilizador puder fazer mais de uma review para cada parque, caso contrário o campo está a mais;

- a tabela "precos" tem a mesma nota acima;

- a tabela "epocas" talvez devesse ter um nome ou descrição e não só um intervalo de tempo, para se poder ter algo do género, "Primavera-Verão 2006"

- os contactos da tabela "parques", estando OK, poderiam estar numa tabela à parte, havendo depois tipos de contactos e contactos, como disse tal como está está correcto, mas a gestão dos contactos é muitas vezes feita "à parte", depende também das necessidades, por exemplo, um parque pode ter 3 fax e outro pode não ter nenhum.

De resto, o modelo parece OK. :D

Muito obrigado pela revisão :P

Só não tou a conseguir "visualizar" a razão do campo id estar a mais na tabela 'reviews' e 'precos'.. n tenho muita experiência em bases de dados (como já se deve ter reparado!), tenho tentado aprender por mim próprio então ainda tenho dificuldades e "ver" como é que os dados vão ficar no fim. Portanto a razão.. tem a ver com o facto de qualquer combinação "id_parque/id_user ser única, ou seja, cada user só pode ter um review por parque, ok acho que entretanto já se fez luz, hehe :P

Na tabela 'precos' é a mm coisa, ou seja, cada parque, para cada época, só tem um conjunto de preços. Estou a ver bem as coisas?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Quanto ao modelo de dados apresentado:

- a tabela "reviews só necessita do campo id se um utilizador puder fazer mais de uma review para cada parque, caso contrário o campo está a mais;

- a tabela "precos" tem a mesma nota acima;

- a tabela "epocas" talvez devesse ter um nome ou descrição e não só um intervalo de tempo, para se poder ter algo do género, "Primavera-Verão 2006"

- os contactos da tabela "parques", estando OK, poderiam estar numa tabela à parte, havendo depois tipos de contactos e contactos, como disse tal como está está correcto, mas a gestão dos contactos é muitas vezes feita "à parte", depende também das necessidades, por exemplo, um parque pode ter 3 fax e outro pode não ter nenhum.

De resto, o modelo parece OK. :D

Muito obrigado pela revisão :)

Só não tou a conseguir "visualizar" a razão do campo id estar a mais na tabela 'reviews' e 'precos'.. n tenho muita experiência em bases de dados (como já se deve ter reparado!), tenho tentado aprender por mim próprio então ainda tenho dificuldades e "ver" como é que os dados vão ficar no fim. Portanto a razão.. tem a ver com o facto de qualquer combinação "id_parque/id_user ser única, ou seja, cada user só pode ter um review por parque, ok acho que entretanto já se fez luz, hehe :P

Na tabela 'precos' é a mm coisa, ou seja, cada parque, para cada época, só tem um conjunto de preços. Estou a ver bem as coisas?

O campo uid está lá para ser a chave da tabela, ou seja, o identificador único. Se disseres que a chave primária da tabela é composta pelos dois ids das outras tabelas, ou seja pelas chaves estrangeiras, então tens o problema do identificador único resolvido. No entanto, tal vai apenas permitir um par desses ids em toda a tabela.

O que dizes para o caso dos preços está correcto, nesse caso não necessitas do id e podes usar o par de ids das chaves estrangeiras como chave. :P

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora