É para isso que a modelagem serve @Xablau. O que você acha mais fácil de ‘captar’ as informações essenciais: um texto ou um gráfico? Um modelo gráfico ou um conjunto de palavras? Com uma modelagem fica mais fácil de você entender o problema e de nós compreendermos as suas ideias e o problema que você suscita. É por isso que as engenharias (inclusive a de software) usa modelagens.
Exemplo:
Pela modelagem, eu descubro, por exemplo (de uma forma nada formal), que o mecânico Zé pode consertar o carro de placa AAA-1111 e o de placa AAB-0123. O carro AAA-1111 pode ser consertado pelo mecânico Geraldo e pelo Mecânico Luís. Sendo mais formal, “Um automóvel pode ser consertado por um ou mais mecânicos. Por outro lado, um mecânico pode consertar um ou mais automóveis”. Logo, na minha modelagem eu tenho uma terceira tabela de relação:
É uma maneira de pensar o problema (a regra de negócio). Nesse caso, na tabela Mantenca haverá as fk para a tabela Automovel e para a tabela Mecanico.
deixa eu ver se eu entendi bem, então o mecanico herdaria os atributos de funcionário como id, nome etc. daí em mecanico teria um atributo ou conjunto de atributos mais específicos como tipo de especialização por exemplo, é isso? ou eu teria que colocar os atributos de funcionario em mecanico como chaves estrangeiras?
eu não sei se consegui me expressar bem, mas se eu tenho uma entidade funcionario com id(PK), nome e idade e uma entidade mecanico que também é funcionario, quais os atributos que eu teria em mecanico?
porque se eu entendi bem o slide a minha entidade mecanico terá um atributo mais específico como funcão por exemplo e não teria nem id, nome ou idade já que esses atributos são de funcionario
outra dúvida que tenho é na minha entidade empresa, que deve armazenar todos os dados de funcionario e clientes, ela terá todos os atributos de cliente e funcionario? e todos os atributos seriam FK?
A herança de uma forma simplista, é um mecanismo que permite transferir propriedades e comportamentos de um ente a outro a ele relacionado de alguma forma. Na Biologia, essa relação é genética. Na computação, mais precisamente no paradigma de Orientação a Objetos, essa relação é estrutural, sendo manifestada por uma hierarquia de entes, esses chamados de classes.
Na POO, a herança visa generalizar as propriedades e comportamentos comuns (colocar no topo) e especializar as propriedades e comportamentos específicos. Essa ideia não é nova. Lembrando por exemplo de Aristóteles, ele dizia que quanto mais informações você fornece sobre uma coisa, mais específico ele se torna. Assim, por exemplo, imagine uma xícara. Há uma infinidade de xícaras. No entanto há um número menos delas se forem azuis, com o logo do Java, e que estejam sobre a minha mesa. Trazendo para o exemplo do funcionário e o mecânico, um funcionário trás poucas informações se comprado a um mecânico. Um funcionário pode ser um profissional de muitas áreas. Ele pode ser um contador, um almoxarife, etc. Já um mecânico é sempre mecânico, do ponto de vista profissional. Desse exemplo, pode se indicar que funcionário é uma generalização de um mecânico, ou, que um mecânico é a especialização de um funcionário. Ou seja, se sobe na hierarquia é mais genérico, se desce é mais especializado.
Um exemplo clássico (digrama de classes):
Logo, era de se supor:
Mas fica a pergunta: do que você leu sobre usar herança ou composição…, um mecânico é um novo tipo de funcionário ou é um papel assumido pelo funcionário?
Um funcionário motorista pode ser mecânico? Se lembrarmos que a herança é uma relação estrutural, isto é fixa, então não do ponto de vista da herança. No entanto, na vida real isso é possível? Sim! Então ao meu ver um mecânico é um papel, uma função, ou uma profissão que um funcionário pode ter. Com base nisso, eu usaria a composição para relacionar essas duas classes. Além disso, a herança pura e simples para reutilizar implementação (herança pobre) deve ser evitada a todo custo.
No entanto se ainda assim você querer usar herança:
1 - Modelo Conceitual
Para não ter uma herança pobre, defini a especialidade do mecânico. Nesse caso, a especialidade pode ser quanto à motorização (etanol, gasolina ou diesel), ao tipo de veículo, (veículos leves ou pesados), etc.
2 - Modelo lógico
Aquele link que passei sobre a conversão MER para Relacional está incompleto. Há três possibilidades:
2.1 - Criando uma tabela apenas para a entidade pai
Nessa abordagem haverá muitos valores nulos, uma vez que dado o tipo do objeto somente os atributos referentes aquele objeto serão preenchidos. Por isso, nem todos os atributos serão obrigatórios. Por outro lado, tem a vantagem de dispensar a necessidade de junção entre tabelas, uma vez que os dados estão todos na mesma tabela.
2.2 - Criando tabelas apenas para as entidades filhas
É pouco recomendada, porque pode gerar redundância de dados, uma vez que os dados da entidade genérica são repetidos em todas tabelas especializadas. Assim, se uma pessoa for tanto professor quanto aluno, teremos informações referentes a essa pessoa repetida nas duas tabelas. Essa abordagem só deve ser utilizada quando tivermos uma especialização exclusiva.
2.3 - Criando uma tabela para cada entidade (tanto para a entidade pai, quanto para filhas)
Tem a vantagem de evitar os valores nulos que aparecem na primeira abordagem e ainda não permite a duplicidade como na segunda abordagem.
O certo seria um tabela para cada coisa. Uma para empresa e uma para cliente. Daí o relacionamento entre essas classes permite cruzar as informações. Uma coisa interessante a se perceber é que se deve evitar ter duas ou mais tabelas com os mesmos valores. Atente para a normalização (as FNs).
Exemplo:
Com o intuito de manter informação que podem se repetir em classes adequadas, pode-se pensar como acima, mas daí surgem alguns problemas como a complexidade. Pelo digrama de classes acima começa-se a perceber se há a real necessidade de haver a classe funcionario. Mas depende da sua regra de negócio, como tu pensa o sistema. Por isso é muito importante e salutar fazer a modelagens, sejas das classes, seja do banco de dados:
