PplWare Mobile

Estruturação de uma Base de Dados


Autor: Manuel Rocha


  1. Miguel Goyanes says:

    5* Manuel
    Dúvida. A imagem “imagem_estruturacao_bd10.jpg” é feita com??

    Abraço,

    Miguel Goyanes

  2. Johny says:

    parece-me que é com o micro$oft access

  3. Progster says:

    Boa tarde.

    A imagem em questão foi feita em Access.

    Cumprimentos.

  4. Tiago says:

    Microsoft Office Access (2003/2007/2010)

  5. Muitos parabéns sobre o artigo, muito completo e de fácil compreensão.

    Ainda hoje, apanhei uma seca com alguns dos conteúdos apresentados acima que com este artigo era muito simples de entender.

  6. Belo Artigo , esta penando em tornar isso um manue, assim como foi o de sql?

  7. Gilito says:

    Boas…

    Não sendo eu especialista em bases de dados, recomendaria alguma prudência aos mais “novos” na utilização de relações 1-1.

    Bem sei que o exemplo apresentado serve apenas para ilustrar o conceito, mas mesmo assim já dá para levantar alguns problemas deste tipo de relações.

    O principal cuidado a ter com este tipo de relações é que apenas devem ser consideradas quando de facto o item da tabela “forasteira” for obrigatório, isto é, se for obrigatoriamente necessário uma Pessoa ter BI…

    Caso contrário, levaria a que houvesse uma chave forasteira a NULL (poderia ser criado um registo de default, mas… 🙁 ).

    Exemplo concreto: Pegando no mesmo exemplo, poderíamos tentar fazer o mesmo para o NIF (Numero de Identificação Fiscal), mas a verdade é que é possível ser Pessoa durante muitos anos sem que tenha que ter um NIF… pelo que na nossa tabela teríamos uma chave forasteira a NULL…

    Salvo raras excepções, em que por questões de desempenho é absolutamente necessário “normalizar” uma tabela de modo a dar origem a uma relação 1-1, na generalidade dos casos mais vale ter esses dados na tabela “principal”, neste caso, na tabela Pessoa.

    Mais informações sobre este tipo de relações aqui: http://stackoverflow.com/questions/517417/is-there-ever-a-time-where-using-a-database-11-relationship-makes-sense

    Cumprimentos e espero ter ajudado!

    Gilito

    • Manuel Rocha says:

      Viva Gilito,

      Realmente o reparo é de ter em consideração, mas neste caso o que se pretende é mesmo ilustrar a relação para que a pessoa perceba. Penso que a situação que descreves daria outro post que viria complementar este, tipo Parte 2.

      No entanto, penso que o nosso amigo Progster pode escrever algo nesse aspecto.

      Cumprimentos,
      Manuel Rocha

    • Progster says:

      Boa noite.

      A uma pessoa pertence só um, e um só BI, e o mesmo se aplica ao NIF.

      Fica é ao critério de cada um a escolha de qual entidade recebe a chave estrangeira.

      Cumprimentos.

      • Nunca entendi bem essa relação, sendo assim bastava dizer que o bi é um campo da tabela/entidade pessoa.

        • jgonca says:

          Isso dependerá do dados que quiseres guardar… Se quiseres guardar só o nº de BI, era capaz de ser o mais fácil. O “problema” existiria se quisesses guardar mais dados relativos ao BI (arquivo, data de validade, data de emissão, etc). Aí já faria sentido criar uma tabela de BIs com a toda a informação relativa aos mesmos, pois manterias a arquitectura da base de dados normalizada (3ª forma normal).

          Corrijam-me se estiver errado… 🙂

        • Manuel Rocha says:

          Viva João,

          A tua interpretação está correcta. No entanto, se separarmos o BI da tabela de pessoa podemos fazer um indexação a esse mesmo campo e torna-se mais rápido para realizar pesquisas, sendo que depois só necessitamos retornar a linha correspondente aquela chave.

          Todavia não é de todo errado colocares na mesma tabela mas podes comprometer a performance das queries.

          Há quem coloque inclusivé cada parte do nome separadas por várias tabelas pela mesma razão do descrito. Enfim, são opiniões, não podemos dizer que esta forma está errada assim como também não podemos dizer que a tua também está, mas tudo vai por questões de performance. Eu colocaria como tu dizes mas se visse uma base de dados com um relacionamento destes também não questionava.

          Cumprimentos,
          Manuel Rocha

          • bastos says:

            Concordo plenamente que qualquer abordagem estaria correctas…No entanto creio que tudo depende realmente do que se quer atingir…Como já foi dito aqui mesmo pelo Progster: “Fica ao critério de cada um dependendo das suas necessidades”..

            Creio que não se pode centrar o facto de decisão apenas em performance… Sim, tem um grande peso, sem duvida… Mas não se poderia criar mais um “index” na coluna especifica se estivesse na mesma tabela?

            Abraço!

          • Obrigado pelo esclarecimento, fiquei a perceber a ideia.

        • Progster says:

          Boa noite.

          Sim, penso que se pode aceitar essa afirmação, mas também podem ocorrer situações em que é necessário ter uma tabela para Números de BI.

          Fica ao critério de cada um dependendo das suas necessidades.

          Cumprimentos.

      • Gilito says:

        Boas…

        Isso não invalida o que eu disse…

        Pensando ao contrário, teríamos que ter a certeza que um NIF ou BI está *obrigatoriamente* associado a uma Pessoa…

        Cumprimentos…

        Gilito

        • Progster says:

          Boa noite.

          Quando se desenvolve uma BD, há que “pensar” tanto na prespectiva do programador, como do futuro utilizador, logo se é ou não obrigatório usar no modelo ER, tanto o número de BI, como o NIF, fica ao critério de cada um de acordo com as suas necessidades.

          Se é isto que estás a querer dizer então estou de acordo contigo.

          Cumprimentos.

    • Duarte Brito says:

      Oh Gilito, penso que estarás a ser muito especifico…
      Penso que a resposta ao problema que colocas é… Depende (Como quase sempre no mundo da informática).

      Sendo assim, por aquilo que defendes, no caso do T-SQL, os INNER JOIN’s poucas vezes seriam utilizados e para quê um OUTER JOIN…

      Primeiro exemplo… Tens uma BD com 30000 pessoas em que 15000 tem BI’s… Se precisar de uma propriedade do BI eu vou trabalhar com um total de 15000 registos, se fosse pela tua teoria iria trabalhar sobre 30000 registos onde 15000 seriam desnecessários… (Exemplo onde refuto a tua teoria)

      Segundo exemplo… Eu trabalho com SSAS todos os dias muito focado em Cubos… Neste caso eu preciso ter tabelas de Factos e Dimensões… É sempre útil ter as tabelas desnormalizadas… Porque é assim que a coisa funciona mesmo… (Exemplo onde apoio a tua teoria)

      Por isso volto a dizer…. Depende…

      Mas para além de isto tudo, concordo é mesmo com o Manuel Rocha… Para o post que era, está muito bem conseguido…

      Cumprimentos.

      • Manuel Rocha says:

        Viva Duarte Brito,

        O teu segundo exemplo tocou num ponto que daria um outro artigo interessante, em que se mostraria a diferença entre bases de dados OLAP (onde temos as tabelas factos e dimensões que referes) e OLTP.

        Cumprimentos,
        Manuel Rocha

        • Progster says:

          Boa noite.

          Também me parece a ser um tema interessante.

          Vou fazer umas pesquisas sobre o assunto.

          Cumprimentos.

        • Duarte Brito says:

          OLAP, ROLAP, e MOLAP… Já testei as 3 e fazem bastante diferença no acesso a dados… Mas lá está depende…

          • Sérgio Costa says:

            Sim o que dizes é verdade, mas é importante realçar que a finalidade de uma BD é diferente daquela que é esperada de um modelo de dados multi-dimensional, alias, estes são posteriormente criados através destas, e como sabemos, quanto mais “desnormalizados” estiverem melhor é, facilitando o acesso a informação.

        • M.Manuelito says:

          Seria interessante um artigo sobre bases de dados OLAP!
          E também seriam certamente bem vindos uns artigos sobre MS Access, para mim uma das ferramentas mais interessantes do pacote MS Office! Fica a ideia 🙂

        • xpoto says:

          Bases de dados OLAP? ou bases de dados multi-dimensionais? acho que é a segunda, neste caso Datas Warehouse.

      • Gilito says:

        Boas… (mais uma vez)

        Com o meu primeiro comentário não foi de modo algum minha intenção tirar o mérito de quem escreveu o artigo, nem baralhar ninguém…

        Quis apenas alertar para uma questão que pode ser colocada pelos mais “novos” nestas andanças e poderiam desatar a fazer relações do tipo 1-1 a torto e a direito… creio que este artigo não era destinado a programadores com 10-15 anos de experiência…

        Tal como disse, e creio que vocês concordam, este tipo de relações é especialmente útil por questões de desempenho… que para os mais “novos” se calhar não é a preocupação principal… e como tal, uma relação do tipo 1-1 acaba por ser uma excepção…

        Seja como for, parabéns ao autor e fico à espera de mais coisas destas… 🙂

        Ahh só mais uma questão, não tenho a certeza, mas criar uma relação do tipo 1-1 creio que não é propriamente normalizar uma tabela… mas isso fica para o próximo artigo…

        Cumprimentos,

        Gilito.

        • Progster says:

          Boa noite.

          Não há problema nenhum, de todo assim foi interpretado. Como já referi anteriormente algumas vezes é um artigo destinado a ajudar qualquer pessoa a dar os primeiros passos no desenvolvimento de BD’s, logo como é obvio de modo algum é destinado a programadores com 15-30 anos de experiência.

          Normalmente os mais “novos” (não generalizando)optam entre outras pelo Access, pois é uma ferramenta bastante utilizada e conhecida. Pessoalmente não é uma relação que costumo utilizar com frequência.

          O objectivo da sua utilização como também já foi referido, é exemplificar os tipos de relações existentes, e sim, faz parte da normalização das tabelas, dependendo dos casos.

          Quanto á questão de mais artigos, tudo depende das sugestões, e da disponibilidade.

          • M.Manuelito says:

            @Progster
            Desculpa responder-te aqui mas no comentário acima não aparece a opção responder.
            Na minha modesta opinião e no que toca ao MS Access acho que, seriam bem vindos uma série de tutoriais, logo com início na definição das tabelas, campos, tipo de dados de cada campo, passando pelas relações entre as tabelas, as consultas, formulários, relatórios, eventualmente algum código VBA para algumas funções mais simples, etc.
            Tudo isto numa sequência que permitisse construir uma aplicação completa (lista telefónica, BD de dvd´s /cd´s, etc) que permitisse demonstrar algumas das enormes capacidades do MS Access, e como com esta base de dados se conseguem construir aplicações úteis, quer para uso doméstico, quer para uso numa pequena/media empresa ou organização.
            Fica a sugestão
            Cumprimentos

        • JM says:

          Num relacionamento 1 para 1, e caso a participação seja obrigatória em ambas as entidades, faz todo o sentido fundir ambas as tabelas em apenas uma, aplicando um indice (caso haja necessidade) no BI. Com isto, ganhamos desempenho em futuras pesquisas pois não é necessário efectuarmos a junção entre duas tabelas (Pessoa e BI). Isto não é uma regra rígida, mas é uma boa prática.

          Caso a participação seja opcional numa das entidades, normalmente separa-se, mas pode ser vantajoso (novamente) fundir as duas tabelas numa só.

          Cada caso é único e a sua implementação pode variar de projecto para projecto.

          Espero ter contribuido com algo :)!

          • Gilito says:

            Boas (mais uma e última vez, prometo!)

            Entendido Progster! Exacto JM!

            A questão que eu levantei, teve por base o exemplo que o Progster deu, em que:

            “cabe ao “criador” do modelo entidade-relação a escolha de qual a tabela que irá receber a chave estrangeira.”

            O que basicamente ele quis dizer, foi: ” cabe ao “criador” do modelo definir onde há obrigatoriedade…” (mas sim, para um artigo introdutório a forma como foi dito, é correcta…)

            Neste exemplo, assume-se que não há obrigatoriedade dos dois lados (das duas tabelas) e também não se dá o caso de não haver obrigatoriedade em nenhum dos lados, caso em que originaria uma terceira tabela (semelhante à da relação m:n).

            Assim sendo, das duas uma: ou há obrigatoriamente um registo na tabela BI para cada Pessoa (ou vice-versa) ou então são permitidos valores nulos para uma chave forasteira, algo que sempre me foi “vendido” como desaconselhado (mas possível!)…

            E pronto… creio que já chega de bases de dados por hoje…

            A título de sugestão para futuros artigos, deixo o tema “Google Fusion Tables”…

            Cumprimentos,

            Gilito

    • Pedro says:

      O ideal é os campos BI e NIF não serem chaves, dado que cpodem ser NULL (BI é null num estrangeiro e NIF é null num recem nascido)….Estes campos podem ficar UNIQUE e criar um campo aleatorio para fazer de chave

  8. Tiago Correia says:

    Este artigo vai-me servir de estudo! Muito obrigado desde já pplwarianos.

    • Progster says:

      Boa noite.

      Boa…, a intenção é mesmo essa, ajudar as pessoas a darem os primeiros passos no desenvolvimento de BD’s, de modo a que consigam progredir por si próprias.

      Cumprimentos.

  9. jesus says:

    Bom artigo com certeza. Mas as relações e a normalização de bases de dados dependem em muito dos resultados pretendidos, do n.º de registos da rapidez de acesso aos dados. Eu pessoalmente prefiro não utilizar a normalização nem a relação explicita, vou construindo cada uma conforme a necessidade, pois é mais fácil programar os formulários.

    • Progster says:

      Boa noite.

      Exactamente, existem várias variáveis a ter em conta aquando o desenvolvimento de uma BD, as quais podem, e em muitos casos são mesmo alteradas, de acordo com as necessidades que vão surgindo.

      Cumprimentos.

  10. Damnation says:

    Excelente Progster…

  11. Visitante says:

    Access. Dei isto este ano, está bem explicado sim senhor.
    Parabéns e continuação de bom trabalho.

  12. Progster says:

    Boa noite.

    @M.Manuelito

    Ok. Dependendo da disponibilidade, talvez se consiga mais qualquer coisa.

    Cumprimentos.

  13. Luis Mendonça says:

    Boas,

    excelente post. Alguém tem tutoriais de PostGreSQL? Ou recomenda algum que esteja disponível online?

    Obrigado

  14. André says:

    Excelente post! Vem mesmo a calhar, visto que estou a escrever um manual que começa com esta matéria 😀

  15. paulo says:

    Tenho um manual sobre Access disponível no meu site que podem consultar.

    As bases de dados para datawarehouses tem situações de ter as tabelas desnormalizadas e enriquecidas com informações de outras tabelas por forma a reduzir o número de tabelas a que se tem que aceder quando são efectuadas as pesquisas.

    O tipo de perguntas a que uma datawarehouse deve responder em segundos se colocado em queries sobre sistemas correntes podem demorar longos minutos ou horas.

    A análise para bases de dados OLAP começa pela identificação das dimensões necessárias e dos cruzamentos mais interessantes.

    Espero ter ajudado.

  16. Progster says:

    Obrigado a todos.

    Novas ideias estão já a começar a entrar na fase de estruturação.

    Cumprimentos.

  17. Filipe Craveiro says:

    Recomendo a ferramenta PowerDesigner para estruturar e esquematizar estas bases de dados. Podem também depois, a partir do mesmo software criar uma base de dados já com as tabelas, campos e relações criadas 🙂

  18. piu says:

    obviamente foi feito em bloco de notas integralmente

  19. Jose Pereira says:

    Este topico vem mesmo a proposito de uma duvida que tenho no Access. A minha BD tem um forulario principal que tambem é composto por varios subformularios. A questão é que preciso de pesquisar informação nesse formulario principal, mas a pesquisa não é efectuada nos subformularios. Alguem me pode ajudar.
    Obrigado e um abraço.

  20. Ricardo says:

    Bom artigo. Apenas um reparo, talvez não seja o objectivo deste artigo no entanto não é uma boa prática colocar acentuação/espaços no nome das tabelas/campos.

  21. Pereira Garcia says:

    BOUM ARTIGU! AJUDOUME IMEMSO! 🙂

Deixe uma resposta

O seu endereço de email não será publicado.

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

Aviso: Todo e qualquer texto publicado na internet através deste sistema não reflete, necessariamente, a opinião deste site ou do(s) seu(s) autor(es). Os comentários publicados através deste sistema são de exclusiva e integral responsabilidade e autoria dos leitores que dele fizerem uso. A administração deste site reserva-se, desde já, no direito de excluir comentários e textos que julgar ofensivos, difamatórios, caluniosos, preconceituosos ou de alguma forma prejudiciais a terceiros. Textos de caráter promocional ou inseridos no sistema sem a devida identificação do seu autor (nome completo e endereço válido de email) também poderão ser excluídos.