Olá, pessoal. Tudo certo? No artigo de hoje (Modelo Conceitual e Lógico para SEFAZ-SP) trataremos sobre dois importantes assuntos:
Modelo Conceitual: Modelo Entidade-Relacionamento (MER)
Modelo Lógico: Modelo Relacional
Para contextualizar, o projeto de banco de dados é uma etapa crucial no desenvolvimento de sistemas de informação, onde a estrutura e organização dos dados são cuidadosamente planejadas para atender aos requisitos do sistema e garantir eficiência no armazenamento e recuperação das informações.
Este processo é geralmente dividido em três modelos distintos: o modelo conceitual, o modelo lógico e o modelo físico.
Em suma, os modelos conceitual, lógico e físico trabalham em conjunto para transformar os requisitos do sistema em uma estrutura de banco de dados funcional e otimizada.
Este artigo explorará o modelo conceitual e lógico com foco naquilo que está sendo cobrado em concurso público.
Sem mais delongas, vamos lá.
Modelo Conceitual
Iniciando o artigo sobre Modelo Conceitual e Lógico para SEFAZ-SP, vejamos inicialmente sobre o modelo conceitual.
O modelo conceitual estabelece uma visão abstrata do banco de dados, identificando as entidades principais e os relacionamentos entre elas. Ele fornece uma compreensão de alto nível do domínio do problema e serve como base para os modelos subsequentes.
Perfeito, agora vejamos sobre o Modelo Entidade-Relacionamento no contexto do Modelo Conceitual.
Modelo Entidade-Relacionamento (MER): descreve um contexto (“mini-mundo”) em termos de entidades, relacionamentos e atributos.
Modelo Entidade-Relacionamento (MER)
Entidade: conjunto de coisas ou objetos envolvidos em um contexto específico, podendo ser concretos ou abstratos
Tipos de Entidade:
Forte (independente): existência independe de outras entidades
Fraca: a existência depende de outra entidade (Condição 1) e não pode ser identificada unicamente apenas por seus atributos (Condição 2)
Associativa: a associação de uma entidade a um relacionamento
Relacionamento: é a relação existente entre entidades
Classificação de Relacionamentos
Quanto ao Grau: número de tipos de entidades que participam de um relacionamento – ex. binário
Quanto à Cardinalidade: Representa a quantidade de ocorrências ou instâncias de cada entidade presente no relacionamento – ex. 1:1, 1:N.
Restrição:
Participação Total: toda instância de uma Entidade A deve possuir uma ou mais instâncias de uma Entidade B associada a ela. – ex. 1:1 ou 1:N
Participação Parcial: nem toda instância de uma Entidade A deve possuir uma instância de uma Entidade B associada a ela. – ex. 0:1 ou 0:N
Outras informações:
Cardinalidade mínima (restrição de participação): 0 (cardinalidade mínima opcional -ex. 0:N) ou 1 (cardinalidade mínima obrigatória – ex. 1:N)
Cardinalidade máxima (razão da cardinalidade): 1 ou N
Atributos: descrevem as características de uma entidade ou relacionamento.
Classificação dos Atributos
Quanto ao valor: monovalorado ou multivalorado
Quanto ao Identificador: com identificador (círculo preto, sublinhado ou asterisco) ou sem identificador → um identificador representa uma ocorrência de forma única – ex. CPF.
Notação do Diagrama Entidade-Relacionamento (DER)
Além disso, é válido conhecer a notação DER.
Notação do Diagrama Entidade-Relacionamento (DER)
Notação Pé-de-Galinha (Crow’s Foot)
Continuando no artigo sobre Modelo Conceitual e Lógico para SEFAZ-SP, é válido conhecer a Notação Pé-de-Galinha (Crow’s Foot), que vez ou outra é cobrada em prova.
A entidade é representada da seguinte forma.
Enquanto a cardinalidade temos que:
Além disso, temos as seguintes notações de relacionamento.
Modelo Lógico
Prosseguindo no artigo sobre Modelo Conceitual e Lógico para SEFAZ-SP, vamos entender um pouco melhor sobre modelo lógico.
O modelo lógico traduz o modelo conceitual em estruturas de dados específicas para o sistema de gerenciamento de banco de dados (SGBD) que será utilizado. Aqui, as entidades são mapeadas para tabelas, e os relacionamentos são definidos por chaves primárias e estrangeiras. Restrições de integridade e outras regras de negócio também são especificadas neste nível.
Também é válido saber que existem outras implementações além do Modelo Relacional, como Modelo em rede, hierárquico, entre outros.
Modelo Relacional
Agora vamos tratar sobre o Modelo Relacional.
Modelo Relacional: é capaz de representar dados por meio de uma linguagem matemática, utilizando teoria de conjuntos e lógica de predicado de primeira ordem
É muito importante se familiarizar com as nomenclaturas.
Tabela (Relação): representa os dados e os relacionamentos entre dados
Linha (Tupla/Instância/Registro): valores de dados
Coluna (atributo/campo): dados ajudam a interpretar o significado dos valores
Tipo de dado (domínio): descreve os tipos de valores que podem ser exibidos na coluna
Grau (aridade): número de coluna na relação
Além disso, temos algumas características relevantes em relação a tuplas e atributos.
Ordenação de tuplas: não faz diferença
Valores em tuplas: a ordenação dos atributos/colunas pode ser relevante dependendo do nível de abstração.
Valores e nulls: Cada valor em uma tupla é um valor atômico (não divisível), logo os atributos compostos ou multivalorados não são permitidos. Entretanto, é possível, em regra (exceto a chave primária), os valores nulls.
Operações
No modelo relacional, os dados estão dispostos em tabelas (relações), assim as Operações de Álgebra Relacional é uma forma de manipular os dados que estão nas tabelas, dispostas em linhas (tupla) e colunas (atributo).
Operações de Álgebra Relacional
Seleção: uma operação que filtra as linhas de uma tabela que satisfazem um conjunto de condições
Projeção: projeta as colunas especificadas na lista de atributos.
Produto cartesiano: operação binária que produz um resultado que combina as linhas de uma tabela com as linhas de outra tabela. O resultado contempla todas as combinações das duas tabelas.
Junção: produz um resultado que combina as linhas de uma tabela com as linhas de outra tabela (sem repetição/coluna duplicada).
União: produz como resultado uma nova tabela que contém todas as linhas da primeira tabela seguidas de todas as linhas da segunda tabela. Essa operação somente pode ser realizada se as tabelas forem união compatíveis, isto é, possuírem a mesma estrutura
Intersecção: resulta em uma tabela que contém todos os elementos que são comuns às duas tabelas, sem repetições
Diferença: resulta em uma tabela que contém todas as linhas que existem na primeira tabela e não existem na segunda tabela.
Outros componentes
Continuando no Modelo Conceitual e Lógico para SEFAZ-SP, agora conheçamos os conceitos de “View” e “Indices”.
View: única tabela (virtual) que é derivada de outras tabelas (reais ou virtuais).
Indices (Index): estrutura de acesso utilizados para otimizar o desempenho de consultas a registros em uma base de dados relacional
primários (clusterizados): identificar exclusivamente cada linha na tabela e define a organização física dos dados na tabela, determina a ordem física dos dados.
secundários (não clusterizados): criado em uma coluna que não é a chave primária da tabela, mas é frequentemente usada como critério de consulta, não determina a ordem física dos dados.
Além disso, um tema extremamente importante é o conceito de chaves. Atenção total nesse ponto.
Chaves:
Superchave (Superkey): conjunto de uma ou mais colunas que, tomadas coletivamente, permitem identificar de maneira unívoca uma linha.
Chave Candidata (Candidate Key): superchaves de tamanho mínimo, candidatas a serem possíveis chaves primárias de uma tabela
Chave primária (Primary Key): chaves cujas colunas são utilizadas para identificar linhas em uma tabela – em geral, vêm sublinhada. É a chave escolhida.
Chave secundária/alternativa (Secondary Key): chaves candidatas a serem possíveis chaves primárias de uma tabela, mas que não foram escolhidas.
Chave estrangeira (foreign key): chaves de uma tabela que fazem referência à chave candidata de outra tabela, ou até mesmo da própria tabela. Fornece uma relação entre tabelas
Chave substituta (Surrogate key): chaves primárias artificiais criadas para identificar de maneira unívoca uma linha
12 Regras de Codd
As Regras de Codd são um conjunto de critérios estabelecidos por Edgar F. Codd para definir um sistema de banco de dados relacional. Elas garantem consistência, integridade e padrões de operação em sistemas de gerenciamento de banco de dados relacionais.
Atente-se que é comum chamarmos de “12 Regras”, mas elas vão da 00 até a 12, logo são 13 regras.
12 Regras de Codd:
Regra 00 – Regra Fundamental/Base: tudo deve ser gerenciado como tabelas (controle de permissão, catálogo de metadados, controle de concorrência e etc.)
Regra 01 – Regra da Informação: Toda a informação deve ser representada em tabelas.
Regra 02 – Regra de Garantia de Acesso: cada dado deve ser acessível logicamente através de uma combinação de nome da tabela, chave primária e valor de coluna.
Regra 03 – Regra do Tratamento Sistemático de Valores Nulos: o sistema deve ser capaz de tratar sistematicamente valores nulos
Regra 04 – Regra do Catálogo Online baseado no Modelo Relacional: o catálogo do banco de dados (metadados) deve ser tratado como parte integrante do banco de dados.
Regra 05 – Regra da Sublinguagem Ampla/Compreensiva de Dados: o Banco de Dados Relacional pode oferecer suporte a múltiplas linguagens e meios de acesso, porém deve existir ao menos uma linguagem que englobe todas as funcionalidades “básicas”.
Regra 06 – Regra da Atualização por meio de Views: se uma determinada view for teoricamente atualizável, deverá ser possível atualizá-la via sistema.
Regra 07 – Regra da Inserção, Atualização e Exclusão de Alto Nível: deve-se ser capaz de realizar inserções, atualizações e exclusões da mesma forma que se consulta.
Regra 08 – Regra da Independência Física de Dados: as aplicações devem ser independentes dos detalhes de armazenamento e acesso.
Regra 09 – Regra da Independência Lógica de Dados: Aplicações e recursos não são afetados logicamente quando de alterações de estruturas de tabela.
Regra 10 – Regra da Independência de Integridade: aplicações não são afetadas quando ocorrem mudanças nas regras de restrições de integridade (ex. referencial, restrição e etc), pois as regras estão no catálogo do sistema (gerenciado pelo SGBD)
Regra 11 – Regra da Independência de Distribuição: Aplicações não são logicamente afetadas quando ocorrem mudanças geográficas de dados.
Regra 12 – Regra da Não-Transposição/Subversão: uma linguagem de baixo nível (linguagem de máquina) não pode ser usada para subverter as regras de integridades e as restrições definidas no nível mais alto (linguagem de usuário)
Notação IDEF1X
Para finalizar o sobre Modelo Conceitual e Lógico para SEFAZ-SP, vejamos a Notação IDEF1X (Integration Definition for Information Modeling), notação aplicada no modelo conceitual
As entidades são representadas da seguinte forma:
Enquanto nos relacionamentos,
Por fim, vejamos as entidades.
Considerações Finais
Pessoal, chegamos ao final do resumo sobre Modelo Conceitual e Lógico para SEFAZ-SP, tema muito importante para a prova, espero que tenha sido útil.
Assim, não deixe de estudar o assunto na íntegra por nossas aulas, além de treinar por meio de questões de concurso em nosso sistema de questões.
Gostou do artigo? Siga-nos
https://www.instagram.com/resumospassarin/
Cursos e Assinaturas
Prepare-se com o melhor material e com quem mais aprova em Concursos Públicos em todo o país!
Concursos Abertos
Concursos 2024
Modelo Conceitual e Lógico para SEFAZ-SP
Créditos:
Acesse também o material de estudo!
