POUCO OI MUITAS TABELAS?
Olá,Pessoal!
Tenho uma dúvida antiga sobre Modelagem de dados.
Na época da faculdade,a resposta que o professor me deu foi uma,a que tenho
visto na prática é [Ô]outra[Ô].
Minha preocupação,é conseguir criar BD modelados do modo certo.
O caso:
Digamos,que tenho uma simples tabela de Funcionários (TbFunc)
.
Além dos dados básicos, como Nome,Endereço e telefone.Costumamos nestes cadastros precisar adicionar campos,como
Departamento,UF,Estado Civil ,Grau de instrução,e documentos diversos (Identidade,CPF,etc...).
Minha dúvida é a seguinte:
Visando modelar meu BD do modo correto, eu deveria criar tabelas separadas
para Departamento,função,UF,Estado Civil,Grau de Instrução,documentos,etc....???????
Obs: Estou perguntando isto,pois teóricamente me parece o certo a se fazer.Mas
na prática o que tenho visto é no [Ô]Máximo[Ô] a criação de uma tabela separada
para Departamento ou UF, e o resto das campos multivalorados fica mesmo armazenado
num único campo da tabela de Funcionário.
Tenho uma dúvida antiga sobre Modelagem de dados.
Na época da faculdade,a resposta que o professor me deu foi uma,a que tenho
visto na prática é [Ô]outra[Ô].
Minha preocupação,é conseguir criar BD modelados do modo certo.
O caso:
Digamos,que tenho uma simples tabela de Funcionários (TbFunc)
.
Além dos dados básicos, como Nome,Endereço e telefone.Costumamos nestes cadastros precisar adicionar campos,como
Departamento,UF,Estado Civil ,Grau de instrução,e documentos diversos (Identidade,CPF,etc...).
Minha dúvida é a seguinte:
Visando modelar meu BD do modo correto, eu deveria criar tabelas separadas
para Departamento,função,UF,Estado Civil,Grau de Instrução,documentos,etc....???????
Obs: Estou perguntando isto,pois teóricamente me parece o certo a se fazer.Mas
na prática o que tenho visto é no [Ô]Máximo[Ô] a criação de uma tabela separada
para Departamento ou UF, e o resto das campos multivalorados fica mesmo armazenado
num único campo da tabela de Funcionário.
Vai depender do negócio que o sistema atende.
Por exemplo a tabela UF em alguns sistemas não é tão necessária pois ela só os estados só são referenciados em uma tabela, e dependendo do alcance do cliente, ele nem vai lidar com dados que seja de estados diferentes, e o mesmo se dá com elementos de domÃnio finito como Estado Civil, Grau de Instrução e Documentos. Já para Endereços, é legal ter uma tabela, pois uma instância de um entidade pode ter mais de um.
Uma tabela define os dados de uma instância (registro) do mundo real, então vc tem que ter em mente coisas do tipo: Um funcionário tá alocado em mais de um Departamento ou Departamento pode ser referenciado por mais uma tabela? Tem mais de um Estado Civil?
O relacionamento de tabela envolve questões de integridade de dados, para evitar granularidade desnecessária. Isso é comum em tabelas com campo pra informar a cidade. Dependendo do usuário, ele pode entrar S.PAULO, SAO PAULO, OU SÃO PAULO, SAMPA e etc. Pra depois fazer uma consulta com Group By para um relatório estatÃstico será o caos.
Por exemplo a tabela UF em alguns sistemas não é tão necessária pois ela só os estados só são referenciados em uma tabela, e dependendo do alcance do cliente, ele nem vai lidar com dados que seja de estados diferentes, e o mesmo se dá com elementos de domÃnio finito como Estado Civil, Grau de Instrução e Documentos. Já para Endereços, é legal ter uma tabela, pois uma instância de um entidade pode ter mais de um.
Uma tabela define os dados de uma instância (registro) do mundo real, então vc tem que ter em mente coisas do tipo: Um funcionário tá alocado em mais de um Departamento ou Departamento pode ser referenciado por mais uma tabela? Tem mais de um Estado Civil?
O relacionamento de tabela envolve questões de integridade de dados, para evitar granularidade desnecessária. Isso é comum em tabelas com campo pra informar a cidade. Dependendo do usuário, ele pode entrar S.PAULO, SAO PAULO, OU SÃO PAULO, SAMPA e etc. Pra depois fazer uma consulta com Group By para um relatório estatÃstico será o caos.
Documentos: Podem ser vários e de vários formatos, então o ideal é uma tabela separada, de preferência com uma outra tabela que especifica regras para cada tipo de documento que por sua vez é outra tabela.
Departamento: Pense na possibilidade de o funcionário pertencer à dois ou mais departamentos.
E por aà vai
Em suma, granular por tipo de [Ô]coisa[Ô], dados do funcionário, são apenas dados pessoais Nome, Data de nascimento, código. Dados que são [Ô]referentes à [Ô] e que podem ter multiplicidade o ideal é que seja usado em uma tabela separada. Quanto mais granulado, mais possibilidades, mas maior a dificuldade(mais trabalhoso)
Departamento: Pense na possibilidade de o funcionário pertencer à dois ou mais departamentos.
E por aà vai
Em suma, granular por tipo de [Ô]coisa[Ô], dados do funcionário, são apenas dados pessoais Nome, Data de nascimento, código. Dados que são [Ô]referentes à [Ô] e que podem ter multiplicidade o ideal é que seja usado em uma tabela separada. Quanto mais granulado, mais possibilidades, mas maior a dificuldade(mais trabalhoso)
Olá,Pessoal!
Eu concordo com Kerlunk.Do que pude entender de
Modelagem na faacculdade,me parece ser correto
ter uma tabela para cada.Ai fica a questão.Se sei o
que é correto,então porque fiz a pergunta?
é que embora eu saibaa que o certo é ter várias tabelas,O que
eu tenho visto são sistemas grandes e profissionais ignorando
isto e [Ô]Simplificando[Ô] aa modelagem usando no máximo uma
tabela de departamento junto com tabelas de cadastro de
funcionário.
Eu concordo com Kerlunk.Do que pude entender de
Modelagem na faacculdade,me parece ser correto
ter uma tabela para cada.Ai fica a questão.Se sei o
que é correto,então porque fiz a pergunta?
é que embora eu saibaa que o certo é ter várias tabelas,O que
eu tenho visto são sistemas grandes e profissionais ignorando
isto e [Ô]Simplificando[Ô] aa modelagem usando no máximo uma
tabela de departamento junto com tabelas de cadastro de
funcionário.
Se você visse os sistemas que eu faço, ia ter até dor de cabeça, alguns [Ô]simples[Ô] tem coisa de 60 tabelas... e múltimas FK...
Tópico encerrado , respostas não são mais permitidas