A definição da filosofia diz que, a filosofia é o estudo de questões gerais e fundamentais sobre a existência, conhecimento, valores, razão, mente, e linguagem; frequentemente colocadas como problemas a se resolver. E se você refletir a respeito, isso é tecnicamente o que fazemos em nossa área. Temos questões a serem indagadas, problemas a serem resolvidos. E você não chega a solução de algo, sem antes filosofar sobre o problema.
Em muitos negócios, estudamos o caráter da tecnologia e suas relações com a sociedade para encontrarmos oportunidades para a satisfação humana, ou seja, a camada de usuários. Pensamos em acomodações, até mesmo em suas experiências e emoções com o uso de nossas soluções e produtos desenvolvidos.
Então vamos filosofar um pouquinho comigo...
A evolução da humanidade pode ser encarada como um trajeto no sentido da aquisição progressiva da capacidade individual da abstração. De um ser intimamente ligado à natureza, o homem tornou-se, ao longo do tempo, um ente isolado, independente e com uma capacidade de introspecção objetiva cada vez maior.
O aparecimento do computador deu-se numa época em que essa capacidade de abstração havia deixado de ser privilégio de alguns e passado a pertencer e ser exercida por todos aqueles cuja educação e ambiente fossem propícios. As informações informais deixaram de satisfazer aos anseios individuais de abstração e objetividade; cada vez são exigidas informações mais objetivas e abstratas. Dentre as informações formais, destacam-se as que podem ser expressadas matematicamente. Estas são as que introduzimos no computador, por meio de dados tratados através de programas, que a máquina executa direta ou indiretamente.
Dados e programas são modelos formais matemáticos de realidade ou de abstrações. Vamos introduzir os vários níveis de abstração envolvidos no processo de tratar informações através da máquina abstrata que é o computador.
Na figura ao lado, apresento um esquema que contém os vários níveis envolvidos em um possível processo de modelagem, levando à criação de uma base de dados.
O nível mais alto é o do mundo real que, do ponto de vista formal, é ainda muito nebuloso. Os objetos do mundo real são os seres, os fatos, as coisas e os organismos sociais.
O segundo nível é o das informações (tratadas de maneira ainda informal) e é caracterizado por relatórios escritos em uma linguagem natural (Português, Inglês, etc.). Esse nível, denominado modelo descritivo, contém a descrição de um universo totalmente inteligível para as pessoas que interagem normalmente com ele. Não há regras formais para se desenvolver esse modelo, pois tanto o mundo real quanto o próprio modelo descritivo não são formais.
O terceiro nível é o das informações formais, em que o modelo desenvolvido passa a ser estritamente formal. Como o objetivo é chegar-se, mais a frente em um modelo computacional, o formalismo a ser adotado é o da matemática. Esses modelos são denominados modelos conceituais, caracterizando-os por símbolos, que devem ter uma conceituação rigorosa.
Nos modelos conceituais aparecem dois aspectos distintos, em geral, misturados nos modelos descritivos: tratam-se das estruturas e da manipulação das informações.
As informações podem ser organizadas estruturalmente. Por exemplo: as informações sobre fornecedores contêm partes referentes ao endereço, que por sua vez é estruturado em local, CEP e cidade, sendo o local subdividido em rua, número e complemento.
O quarto nível é o nível dos dados, que são os símbolos a serem introduzidos no computador, tanto na descrição de estruturas (meta-dados, isto é, os dados que descrevem os dados) quanto naqueles que constituem os dados a serem processados pela máquina.
O quinto e último nível é o nível da máquina, não mais do ponto de vista do usuário, mas dos aspectos internos, ou seja, das representações internas dos dados e programas. O usuário não toma conhecimento desses detalhes. Este nível está ligado a atividade de administração de banco de dados.
Recapitulando:
Modelo Descritivo: Pode ser considerada como descrição de uma realidade, não possui nenhum formalismo. Este é o problema a ser tratado.
Modelo Conceitual: Descrição da realidade sob um aspecto mais formal, apontando informações. É usada como representação de alto nível e considera exclusivamente o ponto de vista do usuário criador dos dados.
Modelo Lógico: Modelo Lógico agrega mais alguns detalhes de implementação.
Modelo Físico: Implementação no banco de dados. Demonstra como os dados são fisicamente armazenados.
Modelar significa criar um modelo que explique as características de funcionamento e comportamento de um software a partir do qual ele será criado, facilitando seu entendimento e seu projeto, através das características principais que evitarão erros de programação, projeto e funcionamento. É uma parte importante do desenho de um sistema de informação. Os modelos de dados são ferramentas que permitem demonstrar como serão construídas as estruturas de dados que darão suporte aos processos de negócio, como esses dados estarão organizados e quais os relacionamentos que pretendemos estabelecer entre eles.
E na engenharia de banco de dados, o processo de criação de uma base, deveria seguir uma cadeia de processos organizada similarmente ao fluxograma abaixo:
Modelo Descritivo
O modelo descritivo auxilia a documentar informações que poderiam passar despercebidas.
Por não ter técnicas específicas, devemos procurar neste momento pensar em sujeitos (pessoas, empresas ou pessoas exercendo uma atividade, por exemplo médico), e devemos escrever sobre eles no modelo descritivo. Outra técnica é a de descrever objetos que fazem parte do contexto (por exemplo Nota Fiscal, ou mesmo produtos vendidos pela empresa).
O foco deve ser o de retratar informações existentes no levantamento das necessidades.
O modelo descritivo servirá de base para o modelo conceitual. Este por sua vez deve ser mais estruturado, porém, ainda não tem uma apresentação visual obrigatória, servindo ainda para um maior detalhamento de informações a serem documentadas para a criação dos modelos lógico e Físico.
Exemplo de Modelo Descritivo
Clínica Médica
Em uma clínica trabalham médicos e existem pacientes internados.
Cada médico é identificado pelo seu CRM, possui um nome e recebe um salário na clínica.
Um médico tem formação em diversas especialidades (ortopedia, traumatologia, etc), mas só exerce uma delas na clínica.
Para todo paciente internado na clínica são cadastrados alguns dados pessoais: nome, RG, CPF, endereço, telefone(s) para contato e data do nascimento.
Um paciente tem sempre um determinado médico como responsável (com um horário de visita diário predeterminado), porém vários outros médicos podem participar do seu tratamento.
Pacientes estão sempre internados em quartos individuais, que são identificados por um número e ficam em um andar da clínica.
A clínica possui duas filiais que estão em outros bairros da cidade de São Paulo.
A clínica possui também terapias complementares aos tratamentos médicos, tais como acupuntura, massagem e Fisioterapia.
Alguns profissionais são empregados da clinica e outros são prestadores de serviço.
Modelo conceitual
O modelo conceitual deve detalhar as informações sem a necessidade de apresentar as informações sob o ponto de vista visual.
Este modelo muitas vezes acaba sendo mesclado com o modelo descritivo tornando um documento único. A importância desse modelo é grande, pois aqui o nível de detalhamento das informações deve ser maior.
Este é o modelo de alto nível em que contém o detalhe menos granular, mas estabelece o escopo global do que está para ser incluído dentro do conjunto do modelo.
Exemplo
A clinica possui as seguintes informações:
- Nome
- Endereço
- Telefone
Os pacientes possuem as seguintes informações:
- Nome
- Identidade
- Endereço
- Telefone
Componentes de Modelagem de Dados
O modelo de dados é formado por três componentes:
Entidade
O mundo está cheio de “coisas” e nós abstraímos coisas semelhantes e chamamos essas abstrações de objetos ou entidades.
O nosso conceito, do que constituem os critérios apropriados para determinar a semelhança, é que eles dependem dos objetos que nós visamos.
Entidades são objetos modelados em função dos papéis que desempenham em um sistema específico.
Uma única entidade do mundo real pode desempenhar papéis diferentes em sistemas diferentes.
Entidades diferentes do mundo real podem desempenhar o mesmo papel em um sistema.
Uma única entidade do mundo real pode desempenhar mais de um papel em um mesmo sistema
Uma entidade é a representação do que nós sabemos sobre o objeto do mundo real.
Da mesma forma que um arquivo é composto por registros, uma entidade representa o conjunto de dados das ocorrências dos objetos do mundo real.
As entidades são abstrações de um conjunto de coisas do mundo real no qual todas as coisas do mundo real do conjunto - as instâncias - tenham as mesmas características e todas as instâncias estejam sujeitas à, e em conformidade com as mesmas regras.
Então de forma bem resumida, o conceito é de que uma entidade é uma categoria de "coisas" concretas ou abstratas do mundo real sobre a qual o "negócio" necessita operar.
Ou seja, uma entidade é uma representação de um conjunto de informações sobre determinado conceito do sistema. Toda entidade possui atributos, que são as informações que referenciam a entidade.
Tecnicamente, uma entidade é um objeto de dado básico do modelo entidade-relacionamento, cujas informações devem ser coletadas. Pode representar, por exemplo, um funcionário, lugar, coisa ou evento do mundo real, de interesse informativo. Uma ocorrência específica de uma entidade é chamada de instância da entidade.
Atributos de uma Entidade
Resumidamente, atributos são fatores, características quaisquer de uma entidade que interessam ao 'negócio'.
Atributos oferecem detalhes descritivos sobre elas. Uma ocorrência em particular de um atributo dentro de uma entidade é chamada de valor de atributo.
Tipos de Entidades
Entidade Tipo
Uma entidade tipo representa um conceito independente em um modelo de dados e está em primeiro lugar na mente do cliente.
As entidades tipo são independentes e, com frequência, constituem o ponto de partida de um modelo de dados.
Muitas vezes essas entidades estão conectadas a outras entidades tipo por meio de um relacionamento 1:m ou m:m.
Como exemplo podemos considerar um sistema acadêmico onde as entidades aluno e curso são entidades tipo, pois a entidade aluno, se não existisse a entidade curso, poderia existir da mesma forma.
Entidade Primária (Forte)
são aquelas cuja existência independe de outras entidades, ou seja, por si só elas já possuem total sentido de existir. Em um sistema de vendas, a entidade produto, por exemplo, independe de quaisquer outras para existir.
Ocorre sempre em casos de Relacionamentos 1 para 1.
Exemplos: Nota Fiscal, Pedido de Venda
Entidade Dependente (Fraca)
Uma entidade fraca (ou dependente) precisa de outra entidade para garantir a sua existência. Essa entidade depende de uma entidade tipo e esta relação de dependência é uma relação obrigatória.
O identificador de uma entidade fraca possui em sua composição os atributos identificadores da entidade tipo à qual a entidade fraca está associada.
Como exemplo podemos considerar um sistema de gestão de recursos humanos onde a entidade dependente é uma entidade fraca em relação à entidade funcionário.
Pois se a entidade Funcionários não existisse, a entidade dependente consequentemente não existiria.
Entidade Associativa
As entidades associativas são o resultados de relacionamentos m:m.
Em geral, as entidades associativas são encontradas entre entidades tipo.
Muitas das vezes, as entidades associativas têm nomes óbvios, pois ocorrem no mundo real.
Por exemplo, a entidade associativa do relacionamento disciplinas e alunos, objetivando o lançamento de notas, chama-se avaliação.
Deve-se sempre procurar pelo nome adequado, pois esse irá aumentar a clareza do modelo de dados.
A entidade associativa é quando a entidade não existe por si só e sua existência está condicionada à existência de duas ou mais entidades, originada em relacionamentos N para N.
Nas imagens abaixo temos como exemplo uma entidade associativa que faz o papel de dois relacionamentos:
E esse relacionamento pode ser substituída e passa a virar uma entidade, como na figura abaixo:
Entidades x Ocorrências
Entidade: é um grupo de ocorrências com definição específica, características e relacionamentos comuns.
Eventos ou Ocorrências: alguns objetos só conseguem ser individualizados ou percebidos enquanto uma certa ação se desenrola (identifica-se características que tornam determinado fato materializável). É um valor especifico da entidade que é chamada de instância ou tupla.
Ex: vôo comercial, acidente de trânsito, jogo de futebol, etc.
Relacionamentos
Neste vídeo eu explico um pouquinho a respeito.
Em engenharia de software, um modelo entidade relacionamento (mais conhecido como MER) é um modelo de dados para descrever os dados ou aspectos de informação de um domínio de negócio ou seus requisitos de processo, de uma maneira abstrata que em última análise se presta a ser implementada em um banco de dados, como um banco de dados relacional.
Os principais componentes dos Modelos Entidade-Relacionamento são as entidades (coisas, objetos) suas relações e armazenamento em bancos de dados.
O processo é modelado como componentes (entidades) que são ligadas umas as outras por relacionamentos que expressam as dependências e exigências entre elas, como: um edifício pode ser dividido em zero ou mais apartamentos, mas um apartamento pode estar localizado em apenas um edifício. Entidades podem ter várias propriedades (atributos) que os caracterizam.
Tipos de relacionamentos
A notação original proposta é composta de entidades (retângulos), relacionamentos (losangos), atributos (elipses) e linhas de conexão (linhas) que indicam a cardinalidade de uma entidade em um relacionamento.
Os tipos de relacionamentos que são utilizadas no diagrama acima:
- Relacionamento 1..1 (lê-se relacionamento um para um) - indica que as tabelas têm relacionamento apenas entre si. Você deve escolher qual tabela receberá a chave estrangeira; A relação de 1 para 1 que existe entre as tabelas de nomes pessoas e endereços, conforme demostrado na figura abaixo:
Ou seja, 1 pessoa possui um endereço e esse endereço pertence a uma pessoa. Levando em consideração de que este relacionamento pode ser questionável mediante ao fator de que um endereço pode morar mais de uma pessoa, mas, no nosso exemplo, vamos dizer fingir que não... xiiu!
- Relacionamento 1..n (lê-se um para muitos) - São relacionamentos em que uma ocorrência de uma tabela A, está associada a uma ou muitas ocorrências na tabela B. A chave primária da tabela A que tem o lado 1 vai para a tabela do lado N. No lado N ela é chamada de chave estrangeira;
Outro exemplo fácil de lembrar, é que um cliente pode fazer diversas compras, que por sua vez, são representadas por diversas notas fiscais. Mas em uma nota fiscal, consta apenas um cliente.
- Relacionamento n..n (lê-se muitos para muitos) - São relacionamentos em que uma ou várias ocorrências de uma tabela A, está associada a uma ou várias ocorrências na tabela B. É um tipo de relacionamento que acontece de forma indireta entre duas tabelas, para que ela seja relacionada, é necessário a geração de uma terceira tabela com as chaves primárias das tabelas envolvidas, ficando assim uma chave composta, ou seja, formada por diversos campos-chave de outras tabelas. O relacionamento então se reduz para uma relacionamento 1..n, sendo que o lado n ficará com a nova tabela criada.
Cardinalidade em Relacionamentos
Em modelagem de dados a cardinalidade é um dos princípios fundamentais sobre relacionamento de um banco de dados relacional. Nela são definidos o graus de relação entre duas entidades ou tabelas.
No modelo relacional, podemos ter os seguintes níveis de relacionamento: 1:N, N:N, 1:1.
Por exemplo, considere um banco de dados desenhado para manter informações relativas a um hospital. Esse banco de dados poderá ter várias tabelas como:
Tabela médico onde constará informações sobre o médico profissional;
Tabela paciente onde constará dados relativos aos assuntos médico e sobre o tratamento do paciente;
Tabela departamento onde será tratado as informações relativas as divisões departamentais do hospital.
Neste modelo teremos o seguinte cenário:
Existirá o relacionamento vários-para-vários (N:N) entre os registros da tabela médico e os registro da tabela paciente, um médico atende diversos pacientes, assim como um paciente pode ser atendido por diversos médicos;
Existirá o relacionamento um-para-vários (1:N) no relacionamento entre a tabela departamento em relação a tabela de médicos, pois um médico, poderá trabalhar em somente um departamento do hospital, contudo, um departamento poderá ter vários médicos.
Já o relacionamento um-para-um (1:1) será usado nos casos onde o registro de uma tabela só poderá ter uma associação com um registro de outra tabela. No nosso caso, isso caberia na relação entre um quarto de apartamento e um paciente. Pois um paciente só poderá estar em um determinado apartamento, e cada apartamento só poderá abrigar um determinado paciente (partindo do princípio de quartos individuais).
Opcionalidade em Relacionamentos
O relacionamento é analisado pelo lado da obrigatoriedade (ou opcionalidade) das ocorrências de um entidade se ligarem às ocorrências de outra.
Opcional
As ocorrências das entidades que se relacionam são independentes das outras.
“Posso ter em um determinado momento no meu banco de dados uma ocorrência da entidade A sem nenhum relacionamento com ocorrências da entidade B?”
Dependendo da Resposta e em função da regra de negócio, o relacionamento será definido. Será opcional caso haja independência entre elas.
Contigente
A obrigatoriedade é somente por um lado do relacionamento e, por conseqüência, somente uma entidade possui independência.
Caso essa seja a regra do negócio, o relacionamento será contigente.
Mandatório
As entidades somente existem se existir o relacionamento entre elas.
Para existirem, as entidades têm que estar relacionadas e formam, portanto, um relacionamento mandatório.
Grau de relacionamento
Representa o número de entidades que participam do relacionamento e são divididos pelos seguintes:
Unário
Auto-relacionamento: Também chamados de recursivo, são casos especiais onde uma entidade se relaciona com si própria. É o que chamamos de amor próprio no mundo real... Apesar de serem relacionamentos muito raros, a sua utilização é muito importante em alguns casos.
Instâncias de mesma entidade
Participam do relacionamento com papéis diferentes
Os auto-relacionamentos podem ser do tipo 1:1 (um-para-um), 1:N (um-para-muitos) ou N:M (muitos-para-muitos), dependendo da política de negócio que estiver envolvida.
Exemplos deste relacionamento podem ser encontrados na chamada “explosão de materiais”, onde itens compostos são formados por muitos itens componentes; por sua vez, estes itens compostos podem ser componentes de outros itens maiores.
Um exemplo de auto-relacionamento é o gerenciamento de funcionários, onde o gerente é um funcionário que possui um relacionamento com outros funcionários que lhe são subordinados. Este relacionamento pode ser representado da seguinte forma:
Binário
Relacionamento Binário: Quando existe o relacionamento entre apenas duas entidades. Esse é o grau de relacionamento mais usado.
Exemplo: Um fornecedor comercializa materiais que são utilizados em diversos projetos.
Ternário
Relacionamento Ternário: Quando existe o relacionamento entre três entidades.
Regra para a determinação das multiplicidades:
Fixa-se dois elementos (dois tipos-entidade)
Verifica-se quantos elementos do outro tipo-entidade podem surgir com relação a um elemento de cada tipo-entidade fixada.
Se a quantidade for indeterminada ou variável
então considera-se n
senão considera-se 1
Exemplo: Um fornecedor comercializa materiais que são utilizados em projetos específicos.
Mais exemplos de Relacionamentos: O Professor leciona Estrutura de Dados e o aluno cursa Linguagem de Programação
Um Modelo Lógico de Dados para uso meramente operacional/transacional não deve conter:
Replicações de atributos: fisicamente pode ser interessante alguma redundância com o objetivo de melhorar a performance de determinado processo. No modelo lógico isso não pode ser feito; um atributo só é representado na Entidade que o pertence.
Atributos derivados: pelos mesmos motivos apontados anteriormente, a implementação das tabelas pode requerer o armazenamento de uma informação derivada de outra (valor do saldo por exemplo). Tal tipo de informação não se constitui um atributo do modelo lógico.
Atributos repetitivos: o uso de atributos repetidos, como Telefone-1 e Telefone-2, não é admitido. Se existe a possibilidade de uma pessoa possuir mais de um telefone, então Telefone deve ser representado como uma entidade, mantendo relacionamento Nx1 com a entidade Pessoa.
Este post foi um extenso resumo dos principais pontos a serem considerados na modelagem de um banco de dados, mas isso não cobre tudo, nos próximos posts vamos aprofundar mais e teremos exemplos usando SQL Database Modeler.
Top comments (0)