As Doze Regras de Codd são um conjunto de (na verdade) treze regras (enumeradas de zero a doze) publicadas pelo cientista da computação Edgar F. Codd em outubro de 1985, com o intuito de definir o que é necessário para que um sistema de gerenciamento de banco de dados possa ser considerado realmente um sistema relacional, ou seja, um SGBDR.

Edgar Frank “Ted” Codd (19 de agosto de 1923 – 18 de abril de 2003) foi um cientista da computação inglês que, enquanto trabalhava para a IBM, inventou o modelo relacional para gerenciamento de banco de dados, a base teórica para bancos de dados relacionais e sistemas de gerenciamento de banco de dados relacionais.

À medida que o modelo relacional de bancos de dados se popularizou no início dos anos 1980, Codd travou uma campanha por vezes complicada para evitar que o termo fosse mal utilizado por fornecedores de bancos de dados que apenas acrescentaram um verniz relacional à tecnologias mais antigas.

Como parte desta campanha, ele publicou suas 12 regras para definir o que constituía um banco de dados relacional. Isso tornou sua posição na IBM cada vez mais difícil, e então ele saiu para formar uma empresa de consultoria com Christopher J. Date e outros.

Edgar Frank Codd

A seguir trago o texto integral traduzido para o português com as 12 regras mais a regra 0, de acordo como publicado em duas matérias na revista Computerworld no mês de outubro de 1985: “Is your DBMS really relational?“, Computerworld. 14/10/1985, Vol. 19, e “Does your DBMS run by the rules?“, Computerworld. 21/10/1985, Vol. 19.

Texto integral traduzido das 12 Regras de Codd

As 12 regras
Por E. F. Codd
Outubro 1985

Doze regras são citadas abaixo como parte de um teste para determinar se um produto que se afirma ser totalmente relacional o é realmente. O emprego do termo “totalmente relacional” neste relatório é ligeiramente mais rigoroso do que no meu artigo de Turing (escrito em 1981). Isso ocorre em parte porque os fornecedores em seus anúncios e manuais traduziram o termo “minimamente relacional” para “totalmente relacional” e em parte porque neste relatório estamos lidando com SGBDs relacionais e não com sistemas relacionais em geral, o que incluiria meros sistemas de relatórios de consultas.

No entanto, as 12 regras tendem a explicar porque é que o suporte total ao modelo relacional é do interesse dos usuários. Nenhum novo requisito é adicionado ao modelo relacional. Posteriormente, um esquema de notas é definido e utilizado para medir o grau de fidelidade ao modelo relacional.

Primeiro, defino essas regras. Embora eu tenha definido cada regra em artigos anteriores, acredito que esta seja a primeira ocorrência de todas as 12 juntas.

Nas regras de oito a 11, especifico e exijo quatro tipos diferentes de independência destinados a proteger os investimentos dos clientes em programas de aplicação, atividades de terminal e treinamento. As regras oito e nove — independência física e lógica dos dados — têm sido amplamente discutidas há muitos anos.

As regras 10 e 11 — independência de integridade e independência de distribuição — são aspectos da abordagem relacional que não receberam atenção adequada até à data, mas que provavelmente se tornarão tão importantes quanto a oito e a nove.

Estas regras se baseiam em uma única regra fundamental, que chamarei de Regra Zero:

Regra Zero.
Regra 0: Para qualquer sistema anunciado como, ou que se alega ser, um sistema de gerenciamento de banco de dados relacional, esse sistema deve ser capaz de gerenciar bancos de dados inteiramente por meio de suas capacidades relacionais.

Esta regra deve ser válida quer o sistema suporte ou não quaisquer capacidades não relacionais de gerenciamento de dados. Qualquer SGBD que não satisfaça esta Regra Zero não vale a pena ser classificado como um SGBD relacional.

Uma consequência desta regra: qualquer sistema que se alega ser um SGBD relacional deve suportar inserção, atualização e exclusão em banco de dados no nível relacional (múltiplos registros por vez). Outra consequência é a necessidade de dar suporte à regra da informação e à regra do acesso garantido.

“Múltiplos registros por vez” inclui como casos especiais aquelas situações em que zero ou um registro é recuperado, inserido, atualizado ou excluído. Em outras palavras, uma relação (tabela) pode ter zero tuplas (linhas) ou uma tupla e ainda assim ser uma relação válida.

Qualquer declaração nos manuais de um sistema alegado ser um SGBD relacional que aconselhe os usuários a reverter para algumas capacidades não relacionais “para alcançar um desempenho aceitável” – ou por qualquer razão que não seja a compatibilidade com programas escritos no passado em sistemas de banco de dados não relacionais – deve ser interpretado como uma desculpa do fornecedor. Tal afirmação indica que o fornecedor não realizou o trabalho necessário para alcançar um bom desempenho com a abordagem relacional.

Qual é o perigo para compradores e usuários de um sistema que é considerado um SGBD relacional e que falha na Regra Zero?

Compradores e usuários esperarão todas as vantagens de um SGBD verdadeiramente relacional e não conseguirão obter essas vantagens. Agora descreverei as 12 regras que, juntamente com os nove recursos estruturais, 18 manipulativos e três de integridade do modelo relacional, determinam em detalhes específicos a extensão da validade da reivindicação de um fornecedor de ter um “SGBD totalmente relacional”.

Todas as 12 regras são motivadas pela Regra Zero definida acima, mas um SGBD pode ser verificado mais facilmente quanto à conformidade com essas 12 do que com a Regra Zero.

A regra da informação.
Regra 1: Todas as informações em um banco de dados relacional são representadas explicitamente no nível lógico e exatamente de uma maneira — por valores em tabelas.

Até mesmo nomes de tabelas, nomes de colunas e nomes de domínio são representados como cadeias de caracteres em algumas tabelas. As tabelas que contêm esses nomes normalmente fazem parte do catálogo interno do sistema. O catálogo é, portanto, uma base de dados relacional em si – dinâmica e ativa e que representa os metadados (dados que descrevem o restante dos dados no sistema). A regra de informação é aplicada não apenas para a produtividade do usuário, mas também para tornar um trabalho razoavelmente simples para os fornecedores de software definir pacotes de software adicionais (como auxílios ao desenvolvimento de aplicativos, sistemas especialistas e assim por diante) que fazem interface com SGBD relacionais e, por definição, estão bem integrados ao SGBD.

Ou seja, esses pacotes recuperam informações já existentes no catálogo e, conforme a necessidade, colocam novas informações no catálogo pelo próprio ato de utilizar o SGBD.

Uma razão adicional para aplicar esta regra é tornar a tarefa do administrador da base de dados de manter a base de dados num estado de integridade geral mais simples e mais eficaz. Não há nada mais embaraçoso para um administrador de base de dados do que ser questionado se a sua base de dados contém certas informações específicas e ele responder, após uma semana de exame da base de dados, que ele não sabe.

Regra de acesso garantido.
Regra 2: É garantido que todo e qualquer dado (valor atômico) em um banco de dados relacional seja logicamente acessível recorrendo a uma combinação de nome de tabela, valor de chave primária e nome de coluna.

Claramente, cada dado em um banco de dados relacional pode ser acessado em uma rica variedade – possivelmente milhares – de maneiras logicamente distintas. No entanto, é importante ter pelo menos uma forma, independente da base de dados relacional específica, que seja garantida, porque a maioria dos conceitos orientados para o computador (como a varredura de endereços sucessivos) foram deliberadamente omitidos do modelo relacional.

Observe que a regra de acesso garantido representa um esquema de endereçamento associativo exclusivo do modelo relacional. A regra não depende em nada do endereçamento usual orientado por computador. No entanto, o conceito de chave primária é uma parte essencial dele.

Tratamento sistemático de valores nulos.
Regra 3: Valores nulos (distintos da sequência de caracteres vazia ou de uma sequência de caracteres em branco e distintos de zero ou qualquer outro número) são suportados em SGBDs totalmente relacionais para representar informações ausentes e informações inaplicáveis de forma sistemática, independente do tipo de dados.

Para suportar integridade do banco de dados, deve ser possível especificar “nulos não permitidos” para cada coluna de chave primária e para quaisquer outras colunas onde o administrador do banco de dados considere uma restrição de integridade apropriada (por exemplo, certas colunas de chave estrangeira).

As técnicas anteriores envolviam a definição de um valor especial (peculiar a cada coluna ou campo) para representar a informação faltante. Isto seria muito assistemático em um banco de dados relacional porque os usuários teriam que empregar técnicas diferentes para cada coluna ou domínio — uma tarefa difícil devido ao alto nível de linguagem em uso (e uma tarefa que acredito que diminuiria a produtividade do usuário).

Catálogo on-line dinâmico baseado no modelo relacional.
Regra 4: A descrição do banco de dados é representada no nível lógico da mesma forma que os dados comuns, de modo que os usuários autorizados possam aplicar à sua interrogação a mesma linguagem relacional que aplicam aos dados regulares.

Uma consequência disso é que cada usuário (seja um programador de aplicação ou um usuário final) precisa aprender apenas um modelo de dados – uma vantagem que os sistemas não relacionais geralmente não oferecem (o IMS da IBM, juntamente com seu dicionário, exige que o usuário aprenda dois modelos de dados distintos).

Outra consequência é que os usuários autorizados podem facilmente estender o catálogo para se tornar um dicionário de dados relacional ativo e completo sempre que o fornecedor não o fizer.

Regra abrangente de sublinguagem de dados.
Regra 5: Um sistema relacional pode suportar diversas linguagens e vários modos de uso de terminal (por exemplo, o modo de preencher as lacunas). No entanto, deve haver pelo menos uma linguagem cujas instruções sejam expressáveis, de acordo com alguma sintaxe bem definida, como cadeias de caracteres e que seja abrangente no suporte a todos os itens a seguir:

• Definição de dados.
• Definição de Views.
• Manipulação de dados (interativa e por programa).
• Restrições de integridade.
• Autorização.
• Limites de transação (início, confirmação e reversão).

A abordagem relacional é altamente dinâmica de forma intencional — ou seja, raramente será necessário interromper a atividade do banco de dados (em contraste com um SGBD não relacional). Portanto, não faz sentido separar os serviços listados acima em linguagens distintas.

Em meados dos anos 70, o Comitê de Planejamento e Requisitos de Padrões Ansi gerou um documento defendendo 42 interfaces distintas e (potencialmente) 42 linguagens distintas para SGBD. Felizmente, essa ideia aparentemente foi abandonada.

Regra de atualização de visões
Regra 6: Todas as visões que são teoricamente atualizáveis também são atualizáveis pelo sistema.

Observe que uma visão é teoricamente atualizável se existir um algoritmo independente de tempo para determinar inequivocamente uma única série de mudanças nas relações de base que terão como efeito precisamente as mudanças solicitadas na visão. A este respeito, “atualização” pretende incluir inserção e exclusão, bem como modificação.

Inserção, atualização e exclusão de alto nível.
Regra 7: A capacidade de tratar uma relação base ou uma relação derivada como um único operando aplica-se não apenas à recuperação de dados, mas também à inserção, atualização e exclusão de dados.

Este requisito dá ao sistema muito mais espaço para otimizar a eficiência de suas ações em tempo de execução. Ele permite que o sistema determine quais caminhos de acesso explorar para obter o código mais eficiente. Também pode ser extremamente importante para obter um tratamento eficiente de transações em um banco de dados distribuído. Neste caso, os usuários prefeririam que os custos de comunicação fossem poupados, evitando a necessidade de transmitir um pedido separado para cada registro obtido de locais remotos.

Independência física de dados.
Regra 8: Os programas aplicativos e as atividades do terminal permanecem logicamente inalterados sempre que qualquer alteração é feita nas representações de armazenamento ou nos métodos de acesso.

Para lidar com isso, o SGBD deve suportar uma fronteira clara e nítida entre os aspectos lógicos e semânticos, por um lado, e os aspectos físicos e de desempenho das tabelas base, por outro; os programas aplicativos devem lidar apenas com os aspectos lógicos.

SGBDs não relacionais raramente fornecem suporte completo para esta regra – na verdade, não conheço nenhum que o faça.

Independência lógica de dados.
Regra 9: Os programas aplicativos e as atividades de terminal permanecem logicamente intactos quando alterações de qualquer tipo que preservem informações e que teoricamente permitam a integridade são feitas nas tabelas base.

Tomemos os dois exemplos a seguir: dividir uma tabela em duas tabelas, seja por linhas usando conteúdo de linha ou por colunas usando nomes de coluna, se as chaves primárias forem preservadas em cada resultado; ou combinar duas tabelas em uma por meio de uma junção sem perdas (os autores da Universidade de Stanford e do MIT chamam essas junções de “sem perdas”). Para fornecer este serviço sempre que possível, o SGBD deve ser capaz de lidar com inserções, atualizações e exclusões em todas as visões que são teoricamente atualizáveis. Esta regra permite que o design do banco de dados lógico seja alterado dinamicamente se, por exemplo, tal alteração melhorar o desempenho.

As regras de independência de dados físicos e lógicos permitem que os projetistas de bancos de dados para SGBDs relacionais cometam erros em seus projetos sem as pesadas penalidades impostas pelos SGBDs não relacionais. Isso, por sua vez, significa que é muito mais fácil começar com um SGBD relacional porque não é necessário tanto planejamento orientado ao desempenho antes da “decolagem”.

Independência de integridade.
Regra 10: As restrições de integridade específicas de um banco de dados relacional em particular devem ser definíveis na sublinguagem de dados relacionais e armazenáveis no catálogo, e não nos programas aplicativos.

Além das duas regras de integridade (integridade de entidade e integridade referencial) que se aplicam a todos os bancos de dados relacionais, há uma necessidade clara de poder especificar restrições de integridade adicionais que reflitam políticas de negócios ou regulamentações governamentais.

Suponha que o modelo relacional seja refletido fielmente. Então, as restrições de integridade adicionais são definidas em termos da sublinguagem de dados de alto nível e das definições armazenadas no catálogo, não nos programas aplicativos. Informações sobre objetos identificados inadequadamente nunca são registradas em um banco de dados relacional. Para ser mais específico, as duas regras de integridade a seguir se aplicam a todos os bancos de dados relacionais:

• Integridade da entidade. Nenhum componente de uma chave primária pode ter um valor nulo.
• Integridade referencial. Para cada valor de chave estrangeira não nulo distinto em um banco de dados relacional, deve existir um valor de chave primária correspondente do mesmo domínio.

Se, como às vezes acontece, as políticas empresariais ou as regulamentações governamentais mudarem, provavelmente será necessário alterar as restrições de integridade. Normalmente, isso pode ser feito em um SGBD totalmente relacional, alterando uma ou mais instruções de integridade armazenadas no catálogo.

Em muitos casos, nem os programas aplicativos nem as atividades do terminal são prejudicadas logicamente.

SGBDs não relacionais raramente suportam esta regra como parte do mecanismo do SGBD, ao qual ela pertence. Em vez disso, eles dependem de um pacote de dicionário, que pode ou não estar presente e pode ser facilmente ignorado.

Independência de distribuição.
Regra 11: Um SGBD relacional possui independência de distribuição.

Por independência de distribuição, quero dizer que o SGBD possui uma sublinguagem de dados que permite que programas aplicativos e atividades de terminal permaneçam logicamente intactos:

• Quando a distribuição de dados é introduzida pela primeira vez (se o SGBD instalado originalmente gerencia apenas dados não distribuídos);
• Quando os dados são redistribuídos (se o SGBD gerencia dados distribuídos).

Note que a definição é cuidadosamente redigida para que tanto o SGBD distribuído quanto o não distribuído possam suportar totalmente a Regra 11. O SQL/DS e DB2 da IBM, Oracle Corp. da Oracle e Ingres da Relational Technology, Inc. (todos não distribuídos nos releases atuais) suportam totalmente esta regra.

Isso foi demonstrado da seguinte forma: programas SQL foram escritos para operar em dados não distribuídos (usando o System R), rodam corretamente em versões distribuídas desses dados (usando System R*, o protótipo do IBM San Jose Research Laboratory), e o projeto distribuído Ingres na Universidade da Califórnia em Berkeley mostrou a mesma capacidade para a linguagem Quel de Ingres.

É importante distinguir o processamento distribuído dos dados distribuídos. No primeiro caso, o trabalho (por exemplo, programas) é transmitido aos dados; neste último caso, os dados são transmitidos para o trabalho. Muitos DBMS não relacionais suportam processamento distribuído, mas não dados distribuídos. Os únicos sistemas que suportam o conceito de fazer com que todos os dados distribuídos pareçam locais são SGBDs relacionais – estes são protótipos no momento.

No caso de um SGBD relacional distribuído, uma única transação pode abranger vários locais remotos. Isso é gerenciado inteiramente nos bastidores – o sistema pode ter que executar a recuperação em vários locais. Cada programa ou atividade de terminal trata a totalidade dos dados como se fossem todos locais do site onde o programa aplicativo ou atividade de terminal está sendo executado.

Um SGBD totalmente relacional que não suporta bancos de dados distribuídos tem a capacidade de ser estendido para fornecer esse suporte, deixando os programas aplicativos e as atividades do terminal logicamente intactos, tanto no momento da distribuição inicial quanto sempre que a redistribuição posterior for feita.

Existem quatro razões importantes pelas quais um SGBD relacional desfruta desta vantagem:

• Flexibilidade de decomposição na decisão de como implantar os dados.
• Poder de recomposição dos operadores relacionais ao combinar os resultados de subtransações executadas em diferentes sites.
• Economia de transmissão resultante do fato de não ser necessário enviar uma mensagem de solicitação para cada registro a ser recuperado de qualquer site remoto.
• Analisabilidade da intenção (devido ao nível muito alto das linguagens relacionais) para uma otimização de execução amplamente melhorada.

Regra de não subversão.
Regra 12: Se um sistema relacional tiver uma linguagem de baixo nível (registro único por vez), esse baixo nível não pode ser usado para subverter ou contornar as regras e restrições de integridade expressas na linguagem relacional de nível superior (múltiplos registros por vez).

Na abordagem relacional, a preservação da integridade é independente da estrutura lógica de dados para alcançar a independência da integridade. Esta regra é extremamente difícil para um sistema “nascido de novo” obedecer porque tal sistema já suporta uma interface abaixo da interface de restrição relacional. Os fornecedores de sistemas “nascidos de novo” não parecem ter dado a devida atenção a este problema.

Essas foram as 12 regras de Codd para sistemas de bancos de dados relacionais. Note que, embora essas regras fossem bastante válidas para a época da publicação dos artigos, sua intenção e seu público, hoje em dia é mais apropriado levar em consideração os artigos batizados de “O Terceiro Manifesto”, escritos por Christopher J. Date e Hugh Darwen sobre o modelo relacional, que podem ser acessados em http://thethirdmanifesto.com.

Fonte do texto e referências: https://reldb.org/c/index.php/twelve-rules/

Aproveite e assista a um vídeo sobre as 12 Regras de Codd no canal da Bóson Treinamentos no YouTube:

Colabore com a Bóson Treinamentos

Ajude o canal adquirindo meus cursos na Udemy:

• Bancos de Dados com MySQL Básico: https://bit.ly/35QdWE4
• Lógica de Programação com Português Estruturado: https://bit.ly/3QKPn22
• Programação em Python do Zero: https://bit.ly/python-boson

Adquira também livros e outros itens na loja da Bóson Treinamentos na Amazon e ajude o canal a se manter e crescer: https://www.amazon.com.br/shop/bosontreinamentos

O post As 12 Regras de Codd para Sistemas de Bancos de Dados Relacionais apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Artigo complementar do Curso Completo de Modelagem de Dados da Bóson Treinamentos no YouTube.

As dependências, em bancos de dados relacionais, são restrições aplicadas sobre atributos, ou que definem a relação entre dois ou mais atributos em uma tabela. As dependências ocorrem quando uma coluna em uma tabela é determinada por outra coluna, ou seja, quando uma coluna depende de outra para fazer sentido.

Um exemplo clássico seria uma tabela de produtos, com campos como Código do Produto, Preço do Produto e Data de Validade. Para saber o preço de um determinado produto é bem evidente que precisamos saber de que produto se trata e, para tal, usamos o código do produto para identificá-lo. Neste caso, dizemos que o preço do produto depende do código do produto armazenado.

Esta é uma forma de dependência, que chamamos de dependência funcional, mas existem outras, que passaremos a estudar a seguir.

Tipos de Dependências entre Atributos

Os tipos de dependências que podem ocorrer em uma tabela de banco de dados são os seguintes:

• Dependência Funcional
• Dependência Funcional Total
• Dependência Funcional Parcial
• Dependência Funcional Transitiva
• Dependência Multivalorada

Vamos explicar cada um deles a partir de agora.

Dependência Funcional

Seja E uma entidade, e X e Y dois atributos quaisquer de E. Dizemos que Y é funcionalmente dependente de X se e somente se cada valor de X tiver associado a ele exatamente um valor de Y.

Simbolicamente:

X → Y

Que lemos como “X determina funcionalmente Y”.

Exemplo

Ex.: Pensando em uma tabela de pedidos; O prazo de entrega de um pedido depende do número do pedido considerado:

Num_Pedido  →  Prazo_Entr_Pedido

O atributo que determina o valor é chamado de Determinante. O outro atributo é chamado de Dependente.

Uma chave primária em uma relação determina funcionalmente todos os outros atributos não-chave na linha.

Dependência Funcional Total

Em uma relação com uma PK composta, um atributo não-chave que dependa dessa PK como um todo, e não somente de parte dela, é dito como possuindo Dependência Funcional Total.

Exemplo

Veja o exemplo a seguir:

Aqui, Quant_produto depende tanto de Num_Pedido quanto de Cod_Produto, ao mesmo tempo.

Obs.: A dependência funcional total só pode ocorrer em tabela com chave primária composta.

Dependência Funcional Parcial

Uma dependência funcional é parcial quando os atributos não-chave não dependem funcionalmente de toda a PK quando esta for composta.

Ou seja, existe uma dependência funcional, mas somente de uma parte da chave primária.

Exemplo

Campo Nome_Disciplina é dependente de Cod_Disciplina, mas não do ID_Aluno.

Dependência Funcional Transitiva

Este tipo de dependência ocorre quando um campo não-chave não depende diretamente da chave primária da tabela (nem mesmo parcialmente), mas depende de um outro campo não-chave na tabela.

Exemplo

No exemplo, o atributo Nome_Vendedor depende funcionalmente do Cód_Vendedor, que não é chave primária na tabela. Já o campo Prazo_Entrega depende da PK, Num_Pedido

Dependência Multivalorada

Ocorre quando, para cada valor de um atributo A, existe um conjunto de valores para outros atributos B e C que estão associados a ele, mas que são independentes entre si.

Representamos a dependência multivalorada assim:

A —>> B

Onde B é a coluna que depende da coluna A.

Exemplo

Neste exemplo, os atributos Ano e Cor são independentes entre si e dependem do modelo do carro. Essas duas colunas são dependentes multivaloradas do atributo Modelo.

Conclusão

Entender as dependências é fundamental durante o processo de modelagem de dados, pois, dependendo do tipo de dependência encontrada será necessário tomar determinadas decisões, como eliminar atributos, criar novas tabelas ou mover atributos entre tabelas, o que ficará bem evidente quando estudarmos os processos de Normalização de Bancos de Dados.

Anterior: O que são Restrições de Integridade em Bancos de Dados
Próximo: O que é um Dicionário de Dados

O post Modelagem de Dados – O que são Dependências em Bancos de Dados apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

O Modelo Entidade-Relacionamento, também conhecido pela sigla MER, é um modelo conceitual amplamente empregado para descrever objetos envolvidos no domínio de um sistema de bancos de dados a ser construído, incluindo seus atributos e relacionamentos.

Um MER permite representar de forma abstrata a estrutura que irá constituir o banco de dados, sendo composto pelos seguintes objetos:

• Entidades
• Atributos
• Relacionamentos

Um modelo entidade relacionamento é uma maneira sistemática de descrever e definir um processo de negócio, o qual é modelado como componentes (entidades) que são ligadas umas às outras por relacionamentos que indicam as dependências entre elas.

As entidades podem ter várias propriedades (atributos) que as caracterizam. Diagramas são criados para representar graficamente as entidades, atributos e relacionamentos, denominados Diagramas Entidade-Relacionamento (DER).

Modelo e Diagrama (MER x DER)

Um Modelo Entidade-Relacionamento, ou MER, é uma lista de entidades, seus atributos e relacionamentos, que traz informações sobre tipos de dados, restrições, descrições de entidades e outras. É comumente representado em forma textual, como uma lista de itens ou conjuntos de valores entre chaves ou parênteses. Por exemplo, uma entidade com seus atributos poderia ser representada em um MER da seguinte forma:

Produtos(IdProduto, NomeProduto, PrecoProduto, QtdeEstoque)

O MER foi desenvolvido pelo cientista da computação Peter Chen e publicado em um artigo em 1976.

Já um Diagrama Entidade-Relacionamento, abreviado como DER, é uma representação gráfica associada a um MER (ou à uma parte dele), permitindo expressar graficamente a estrutura lógica de um banco de dados.

Dr. Peter Chen, criador do Modelo ER

Representação dos Componentes em um DER

Os objetos componentes de um diagrama entidade-relacionamento são graficamente representados por figuras geométricas simples, conectadas por linhas. São elas:

• Retângulos: Representam entidades
• Elipses: Representam atributos
• Losangos: Representam relacionamentos
• Linhas: Conectam os atributos às entidades e as entidades aos relacionamentos

Além disso também podemos representar a Cardinalidade dos relacionamentos em um DER por meio de valores escritos entre parênteses, como por exemplo (1,1) (relacionamento um-para-um). Mais sobre isso na aula específica sobre cardinalidades.

Exemplo de DER

A figura a seguir mostra um Diagrama Entidade-Relacionamento de exemplo, criado com o software brModelo, que representa um sistema de banco de dados criado para gerenciar cursos, alunos e professores em uma faculdade.

Podemos identificar neste DER diversas entidades, como Turma, Curso, Disciplina e Aluno, com seus atributos, e os relacionamentos existentes entre essas entidades, além de suas cardinalidades.

Este DER foi utilizado no pr0jeto prático do curso de Modelagem de Dados disponível no canal do YouTube da Bóson Treinamentos.

O post O Modelo Entidade-Relacionamento: Introdução apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Artigo complementar do Curso Completo de Modelagem de Dados da Bóson Treinamentos no YouTube.

Neste artigo vamos explorar um tópico de elevada importância em modelagem de dados: o conceito de chaves e seus tipos, com algumas dicas de como determinar chaves primárias e estrangeiras em uma tabela, e exemplos.

O que são Chaves em Bancos de Dados

Uma chave consiste em uma ou mais colunas combinadas de uma relação (tabela) cujos valores são usados para identificar de forma exclusiva uma linha ou um conjunto de linhas relacionadas.

Uma chave pode ser única, ou seja, identifica uma única linha em uma tabela, ou ainda não-única, permitindo identificar um conjunto de linhas (registros). A seguir listamos as chaves de acordo com essa classificação:

• Chaves Únicas: Chave Candidata, Chave Composta, Chave Primária, Chave Surrogada (ou ChaveSubstituta), Chave Alternativa
• Chave Não-Única (Non-Unique): Chave Estrangeira

Vamos detalhar um pouco mais cada tipo de chave a partir de agora.

Chave Candidata

• Atributo ou grupo de atributos com o potencial para se tornarem uma chave primária.
• Uma chave candidata que não seja usada como chave primária será conhecida como Chave Alternativa.

Exemplos: Os campos Num_Matrícula e CPF em uma tabela de registro de alunos são chaves candidatas, pois podem ser usados como chave primária.

Chave Primária

• É achave candidata escolhida para ser a chave principal na relação.
• A chave primária identifica de forma exclusiva os registros em uma tabela, não podendo haver repetição de valores nem tampouco valor nulo neste campo.
• Em inglês Primary Key / PK

Podemos indicar uma chave primária em um modelo de dados com um #, por exemplo #Cod_Livro, ou ainda sublinhando o nome do campo, como Cod_Livro.

Chave Estrangeira

• Uma chave estrangeira é uma coluna de uma tabela que estabelece um Relacionamento com a Chave Primária (PK) ou coluna unique de outra tabela relacionada.
• É a partir da chave estrangeira (Inglês: Foreign key / FK) que sabemos com qual registro em uma tabela B um registro em uma tabela A está relacionado. Assim, por exemplo, é possível saber qual livro foi vendido, em um sistema de uma livraria, pois o campo Cod_Livro (chave primária em uma tabela de cadastro de livros) estará presente em uma tabela de registro de vendas como chave estrangeira, apontando para o registro do livro especificado.

Chave Composta

• Trata-se de uma chave que é composta de dois ou mais atributos (colunas) combinados, formando uma combinação única, cujos valores nunca se repetem (mas podem se repetir isoladamente).
• Uma chave composta geralmente é empregada quando não é possível utilizar uma única coluna de uma tabela para identificar de forma exclusiva seus registros.

Chave Surrogada ou Chave Substituta

• Uma chave surrogada é um valor numérico, único, adicionado a uma relação para servir como chave primária, quando nenhuma chave candidata for identificada.
• Não possui significado para os usuários e geralmente fica escondida nas aplicações.
• As chaves substitutas são frequentemente usadas no lugar de uma chave primária composta, para simplificação dos relacionamentos.

Instruções para criação de chaves primárias e estrangeiras

Podemos seguir algumas recomendações simples para identificar e criar chaves primárias e chaves estrangeiras em uma tabela, como por eexmplo:

• Não é possível haver valores duplicados em uma chave primária
• No geral, não é possível alterar o valor de uma chave primária
• Chaves estrangeiras são baseadas em valores de dados, classificadas como ponteiros lógicos
• Um valor de uma chave estrangeira deve corresponder a um valor existente em uma chave primária associada (ou valor de chave única). Caso contrário, deve ser nulo (NULL)
• Uma chave estrangeira deve referenciar uma chave primária ou uma coluna de chave única.

Exemplo de chave primária e chave estrangeira

No exemplo a seguir temos três tabelas relacionadas: tbl_Clientes, tbl_Vendas e tbl_Produtos. A tabela de vendas possui duas chaves estrangeiras, que a relacionam com as tabelas de clientes e de produtos, permitindo assim saber qual produto está incluído na venda, e para qual cliente esse produto foi vendido.

O conceito de Domínio

• O conceito de Domínio em bancos de dados nos permite definir os tipos de dados usados em cada campo de uma tabela ou relação.
• Também permitem especificar valores que são válidos em um campo, de acordo com o tipo de dado e intervalo de valores possível para o tipo.

Conclusão

O conceito de chaves e seus tipos é de crucial importância no desenvolvimento de bancos de dados, pois a partir da determinação do campos que serão chaves primárias e estrangeiras é que poderemos estabelecer os relacionamentos entre as tabelas, em um modelo relacional.

Próximo: Cardinalidades em Relacionamentos

O post Modelagem de Dados – Tipos de Chaves apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Artigo complementar do Curso Completo de Modelagem de Dados da Bóson Treinamentos no YouTube.

A integridade de dados se refere á acurácia, completude e consistência dos dados armazenados em um sistema de banco de dados relacional (ou outro sistema). Isso garante que os dados armazenados possam ser armazenados, consultados e utilizados com confiabilidade, sendo assim dados íntegros – daí o nome integridade de dados.

Trata-se, portanto, da manutenção e garantia da consistência e precisão dos dados, sendo um aspecto crítico no design, implementação e uso de sistemas de armazenamento de dados.

Para que seja possível garantir a integridade dos dados, é necessário conhecer e aplicar determinadas restrições de armazenamento, que chamamos de Restrições de Integridade, que dizem respeito a aspectos como tipos dos dados armazenados, relacionamentos entre colunas de chave primária e estrangeira, possibilidade de haver valores nulos ou não, e regras de negócio específicas importantes requisitadas pelo cliente, por exemplo.

Tipos de Restrições de Integridade

Os tipos de restrições de integridade que estudaremos neste artigo são os seguintes:

• Integridade Referencial
• Integridade de Domínio
• Integridade de Vazio
• Integridade de Chave
• Integridade Definida pelo Usuário

Vamos detalhar cada um deles a partir de agora.

Integridade de Domínio

Valores inseridos em uma coluna devem sempre obedecer à definição dos valores que são permitidos para essa coluna – os valores do domínio.

Ex.: em uma coluna que armazena preços de mercadorias, os valores admitidos são do domínio numérico – ou seja, apenas números. Não há preços usando letras para sua representação.

Integridade de Domínio: Fatores

Os seguintes fatores impactam a integridade de domínio:

• Tipo de Dado do campo
• Representação interna do tipo de dado
• Presença ou não do dado
• Intervalos de valores no domínio
• Conjuntos de valores discretos

Exemplo

Suponha um atributo Preço do Produto: Valor Monetário

• Valor permitido:
  • 25,33
• Valores não permitidos:
  • 25 Reais e 33 centavos
  • -32,33

Neste exemplo, não há preços usando letras ou valores negativos, e o valor 25,33 atende à integridade de domínio (numérico e positivo).

Integridade Referencial

Uma restrição de Integridade Referencial assegura que valores de uma coluna em uma tabela são válidos baseados nos valores em uma outra tabela relacionada.

Ex.: Se um produto de ID 523 foi cadastrado em uma tabela de Vendas, então um produto com ID 523 deve existir na tabela de Produtos relacionada.

Em resumo: cada valor de uma chave estrangeira deve corresponder a um valor de uma chave primária existente. Serve para manter a consistência entre tuplas de duas relações; Aparecem devido aos relacionamentos entre entidades

Exemplo

Atributo Nome_Produto: Caracteres

• Valores permitidos (produtos cadastrados):
  • Água
  • Refrigerante
  • Suco
• Valores não permitidos para venda (não existentes na tabela de produtos):
  • Cerveja

Neste exemplo, há um problema na Tabela de Bebidas: o item Cerveja viola a integridade referencial. Não é possível cadastrar uma venda com esse produto, pois ele não existe na tabela de produtos.

Integridade Referencial: Atualização e Exclusão de Registros

Se um registro for excluído em uma tabela (operações DELETE e TRUNCATE), então os registros relacionados em outras tabelas que o referenciam talvez precisem ser excluídos.

Caso contrário ocorrerá erro. O mesmo se dá com a atualização de registros (operação UPDATE).

Integridade de Vazio

Este tipo de integridade informa se a coluna é obrigatória ou opcional – ou seja, se é possível não inserir um valor na coluna.

Uma coluna de chave primária, por exemplo, sempre deve ter dados inseridos, e nunca pode estar vazia, para nenhum registro.

Valores Nulos – NULL

Um valor NULL significa que não existem dados disponíveis para o campo em particular. É diferente de zero, espaço, string vazia ou tabulação, que consistem em algo armazenado.

Os nulos podem ser problemáticos, pois indicam:

• O valor da coluna não é apropriado;
• O valor não foi inserido;
• O valor é desconhecido.

Exemplos de valores NULL

Suponha uma tabela de cadastro de alunos. Nesta tabela todo aluno deverá ter um nome cadastrado, de modo que esse campo é obrigatório (atributo não-nulo – NOT NULL)

Nem todo aluno possui telefone, portanto esse campo não é obrigatório (atributo nulo)

Valor nulo em uma tabela

Integridade de Chave

Os valores inseridos na coluna de chave primária (PK) devem ser sempre únicos, não admitindo-se repetições nesses valores. Desta forma, as tuplas (registros) serão sempre distintas.

Os valores de chave primária também não podem ser nulos.

Integridade Definida pelo Usuário

Diz respeito a regras de negócio específicas que são definidas pelo usuário do banco de dados. Por exemplo, pode-se definir que uma coluna somente aceitará um conjunto restrito de valores, como por exemplo apenas as siglas dos estados da federação, e mais nenhum outro valor diferente.

Conclusão

Conhecer as formas de integridade de dados é muito importante durante o processo de modelagem de dados, pois, é de crucial importância garantir de forma adequada que os dados armazenados sejam confiáveis e que possam ser utilizados com tranquilidade, senado sempre associados a outros dados, além de estarem sempre disponíveis.

Próximo: Dependências em Bancos de Dados

O post Modelagem de Dados – Restrições de Integridade em Bancos de Dados apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Artigo complementar do Curso Completo de Modelagem de Dados da Bóson Treinamentos no YouTube.

A seguir disponibilizamos todos os códigos SQL das consultas e correções de tabelas que foram empregados nos testes da implementação do banco de dados utilizado no projeto prático do Curso de Modelagem de Dados da Bóson Treinamentos, disponível em nosso canal do YouTube.

A primeira parte traz códigos para correções e a segunda, os testes em si (consultas SQL).

Correções e inserções de dados

-- TESTES FINAIS E CORREÇÕES
-- Alterar campo NOTA da tabela Disc_Hist para tipo FLOAT
ALTER TABLE Disc_Hist
MODIFY COLUMN NOTA FLOAT(4,2);
-- Inserir alguns dados de disciplinas e notas nos históricos, que estavam faltando
INSERT INTO Disc_Hist (Cod_Historico, Cod_Disciplina, Nota, Frequência)
VALUES
(1, 2, 7, 6), -- Marcos - Psicologia Cognitiva (cod 2)
(2, 3, 8.5, 2), -- Beatriz - Programação em C (cod 3)
(3, 1, 6.8, 8); -- Gabriel - Raciocínio Lógico (cod 1)

-- Inserir dados de tipos de telefones e os telefones dos alunos
INSERT INTO Tipo_Telefone (Tipo_Telefone)
VALUES
('Res'),
('Com'),
('Cel'),
('Rec');
INSERT INTO Telefones_Aluno (RA, Cod_Tipo_Telefone, Num_Telefone)
VALUES
(1, 1, 28467853),
(2, 1, 24653298),
(2, 3, 996324521),
(3, 1, 36549875),
(3, 3, 994532165),
(4, 1, 21956345),
(4, 3, 986321452),
(5, 1, 24569832),
(5, 2, 23854696),
(6, 1, 27698753);

Consultas para testes

-- 1. RAs, Nomes e Sobrenomes dos Alunos, Nomes dos Cursos e Períodos das Turmas, ordenados pelo primeiro nome de aluno:
SELECT A.RA, A.Nome_Aluno, A.Sobrenome_Aluno, T.Periodo, C.Nome_Curso
FROM Aluno A
INNER JOIN Curso C
ON C.Cod_Curso = A.Cod_Curso
INNER JOIN Turma T
ON A.Cod_Turma = T.Cod_Turma
ORDER BY A.Nome_Aluno;

-- 2. Todas as disciplinas cursadas por um aluno, com suas respectivas notas:
-- Aluno: RA 3 (Beatriz)
SELECT A.Nome_Aluno, A.Sobrenome_Aluno, D.Nome_Disciplina, DH.Nota
FROM Aluno A
INNER JOIN Aluno_Disc AD
ON A.RA = AD.RA
INNER JOIN Disciplina D
ON D.Cod_Disciplina = AD.Cod_Disciplina
INNER JOIN Historico H
ON A.RA = H.RA
INNER JOIN Disc_Hist DH
ON H.Cod_Historico = DH.Cod_Historico
WHERE A.RA = 3;

-- 3. Nomes e sobrenomes dos professores, e disciplinas que ministram com suas cargas horárias:
SELECT CONCAT(P.Nome_Professor, ' ', P.Sobrenome_Professor) AS Docente,
D.Nome_Disciplina, D.Carga_Horaria
FROM Professor P
INNER JOIN Prof_Disciplina PD
ON P.Cod_Professor = PD.Cod_Professor
INNER JOIN Disciplina D
ON D.Cod_Disciplina = PD.Cod_Disciplina
ORDER BY D.Nome_Disciplina;

-- 4. Gerar "relatório" com nomes, sobrenomes, CPF dos alunos, tipos e números de telefones e endereços completos.
SELECT CONCAT(A.Nome_Aluno, ' ', A.Sobrenome_Aluno) AS Aluno, A.CPF, T.Num_Telefone, CONCAT(TL.Tipo_Logradouro, ' ', E.Nome_Rua, ', ', E.Num_Rua) AS Logradouro, E.Complemento, E.CEP
FROM Aluno A
INNER JOIN Telefones_Aluno T
ON A.RA = T.RA
INNER JOIN Endereco_Aluno E
ON A.RA = E.RA
INNER JOIN Tipo_Logradouro TL
ON TL.Cod_Tipo_Logradouro = E.Cod_Tipo_Logradouro;

-- 5. Listar as disciplinas, indicando seus departamentos, cursos e professores
SELECT Di.Nome_Disciplina, C.Nome_Curso,
CONCAT(P.Nome_Professor, ' ', P.Sobrenome_Professor) AS Docente, De.Nome_Departamento
FROM Disciplina Di
INNER JOIN Departamento De
ON Di.Cod_Departamento = De.Cod_Departamento
INNER JOIN Prof_Disciplina PD
ON Di.Cod_Disciplina = PD.Cod_Disciplina
INNER JOIN Professor P
ON P.Cod_Professor = PD.Cod_Professor
INNER JOIN Curso_Disciplina CD
ON Di.Cod_Disciplina = CD.Cod_Disciplina
INNER JOIN Curso C
ON C.Cod_Curso = CD.Cod_Curso
ORDER BY Di.Nome_Disciplina;

O vídeo a seguir mostra os testes realizados, com as respectivas explicações em detalhes:

O post Modelagem de Dados – Testes no Banco de Dados do Projeto Prático apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Artigo complementar do Curso Completo de Modelagem de Dados da Bóson Treinamentos no YouTube.

Nesta lição vamos conceituar alguns termos-chave importante no área de dados.

Dados x Informação

Dados: São fatos em uma forma primária, que podem ser armazenados em algum meio.

• Ex.: CPF, Nome, Data

Informação: São os fatos organizados de maneira a produzir um significado -> Dados colocados em contexto.

• Ex.: Lista de clientes com seus números de CPF, ordenados.

Metadados

• Definimos Metadados como sendo “Dados sobre os dados”.
• Permitem efetuar a representação e identificação dos dados, garantindo sua consistência e persistência.
• Os Metadados são mantidos no Dicionário de Dados (ou em um Catálogo de Dados).

Bancos de Dados

Um Banco de Dados (BD) é uma coleção organizada de dados. Esses dados são organizados de modo a modelar aspectos do mundo real, para que seja possível efetuar processamento que gere informações relevantes para os usuários a partir desses dados.

Um BD é composto por diversos objetos, tais como: tabelas, esquemas, visões, consultas, relatórios, procedimentos, triggers, entre outros, que são gerenciados por meio do uso de uma aplicação especial denominada Sistema de Gerenciamento de Bancos de Dados (SGBD).

Aplicações dos Bancos de Dados

Os bancos de dados encontram aplicações em inúmeras áreas, tais como:

• Sistemas bancários
• Reservas em hotéis
• Controle de estoque em supermercados
• Catálogo de livros em bibliotecas
• E-commerce
• Receita Federal
• YouTube

SGBD

Sistema de Gerenciamento de Bancos de Dados

• Um SGBD é uma coleção de softwares que permite aos usuários criarem e manterem um ou mais bancos de dados.
• São usados nas tarefas de definição, construção, manipulação e compartilhamento dos bancos de dados entre aplicações e usuários.
• Permitem proteger o banco de dados e mantê-lo ao longo do tempo.

Exemplos de SGBDs

A seguir temos alguns exemplos de SGBDs populares no mercado, listados sem nenhuma ordem específica.

• Oracle Database
• Microsoft SQL Server
• MySQL
• IBM DB2
• SAP Sybase
• MongoDB
• Teradata
• PostgreSQL
• SQLite

Exemplo de SGBDR – SQL Server:

Sistema de Banco de Dados

A figura a seguir ilustra a relação entre usuários, databases, SGBDs e as aplicações que acessam os dados:

Características e Funcionalidades de Bancos de Dados

Um banco de dados possui diversas características importantes, sendo que algumas são listadas a seguir.

• Controle de Redundância
• Múltiplas Visões dos Dados
• Controle de Concorrência
• Backup e Restauração
• Autenticação e Autorização de acesso
• Restrições de Integridade

Estudaremos essas e outras características de um BD ao longo de nosso curso.

Anterior: O que é um Banco de Dados

Próximo: Modelos de Bancos de Dados

O post Conceitos de Dados, Informações e Bancos de Dados apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Artigo complementar do Curso Completo de Modelagem de Dados da Bóson Treinamentos no YouTube.

Abaixo temos os códigos que foram empregados na implementação do banco de dados utilizado no projeto prático do Curso de Modelagem de Dados da Bóson Treinamentos, disponível no canal do YouTube.

Códigos para criação do banco de dados e das suas tabelas:

-- Criar Banco
CREATE DATABASE db_Faculdade;
USE db_Faculdade;

-- Criar Tabelas
CREATE TABLE Departamento (
 Cod_Departamento INT PRIMARY KEY AUTO_INCREMENT,
 Nome_departamento VARCHAR(20) NOT NULL
);

CREATE TABLE Professor (
 Cod_Professor INT PRIMARY KEY AUTO_INCREMENT,
 Nome_Professor VARCHAR(20) NOT NULL,
 Sobrenome_Professor VARCHAR(50) NOT NULL,
 Status_Professor TINYINT,
 Cod_Departamento INT,
 CONSTRAINT fk_Codigo_departamento FOREIGN KEY(Cod_Departamento) REFERENCES Departamento (Cod_Departamento)
);

CREATE TABLE Curso (
 Cod_Curso INT PRIMARY KEY AUTO_INCREMENT,
 Nome_Curso VARCHAR(30),
 Cod_Departamento INT,
 CONSTRAINT fk_Cod_Departamento FOREIGN KEY (Cod_Departamento) REFERENCES Departamento (Cod_Departamento)
);

CREATE TABLE Turma (
 Cod_Turma INT PRIMARY KEY AUTO_INCREMENT,
 Cod_Curso INT,
 Periodo VARCHAR(8),
 Num_Alunos INT,
 Data_Inicio DATE,
 Data_Fim DATE,
CONSTRAINT fk_Cod_Curso FOREIGN KEY (Cod_Curso) REFERENCES Curso (Cod_Curso)
);

CREATE TABLE Disciplina (
 Cod_Disciplina INT PRIMARY KEY AUTO_INCREMENT,
 Cod_Disciplina_Depende INT NULL, /* Auto-relacionamento */
 Nome_Disciplina VARCHAR(30),
 Cod_Departamento INT NOT NULL,
 Carga_Horaria INT NOT NULL,
 Descrição VARCHAR(80),
 Num_Alunos INT NOT NULL,
 CONSTRAINT fk_Cod_Departamento_Disciplina FOREIGN KEY (Cod_Departamento) REFERENCES Departamento (Cod_Departamento),
 CONSTRAINT fk_Cod_Disciplina FOREIGN KEY (Cod_Disciplina_Depende) REFERENCES Disciplina (Cod_Disciplina)
);

CREATE TABLE Prof_Disciplina (
 Cod_Professor INT NOT NULL,
 Cod_Disciplina INT NOT NULL,
 PRIMARY KEY (Cod_Professor, Cod_Disciplina), 
 CONSTRAINT fk_Cod_Professor_Prof FOREIGN KEY (Cod_Professor) REFERENCES Professor (Cod_Professor),
 CONSTRAINT fk_Cod_Disciplina_Prof FOREIGN KEY (Cod_Disciplina) REFERENCES Disciplina (Cod_Disciplina)
);

CREATE TABLE Curso_Disciplina (
 Cod_Curso INT NOT NULL,
 Cod_Disciplina INT NOT NULL,
 PRIMARY KEY (Cod_Curso, Cod_Disciplina), 
 CONSTRAINT fk_Cod_Curso_Disci FOREIGN KEY (Cod_Curso) REFERENCES Curso (Cod_Curso),
 CONSTRAINT fk_Cod_Disciplina_Disci FOREIGN KEY (Cod_Disciplina) REFERENCES Disciplina (Cod_Disciplina)
);

CREATE TABLE Aluno (
 RA INT PRIMARY KEY AUTO_INCREMENT,
 Nome_Aluno VARCHAR(20) NOT NULL,
 Sobrenome_Aluno VARCHAR(20) NOT NULL,
 CPF VARCHAR(11) NOT NULL,
 Status_Aluno TINYINT(1) NOT NULL,
 Cod_Turma INT,
 Sexo VARCHAR(1),
 Cod_Curso INT,
 Nome_Pai VARCHAR(50) NOT NULL,
 Nome_Mae VARCHAR(50) NOT NULL,
 Email VARCHAR(50) NOT NULL,
 Whatsapp VARCHAR(20) NOT NULL,
 CONSTRAINT fk_Cod_Turma_Aluno FOREIGN KEY(Cod_Turma) REFERENCES Turma (Cod_Turma),
 CONSTRAINT fk_Cod_Curso_Aluno FOREIGN KEY(Cod_Curso) REFERENCES Curso (Cod_Curso)
);

CREATE TABLE Aluno_Disc (
 RA INT NOT NULL,
 Cod_Disciplina INT NOT NULL,
 PRIMARY KEY (RA, Cod_Disciplina),
 CONSTRAINT fk_RA_Aluno FOREIGN KEY (RA) REFERENCES Aluno (RA),
 CONSTRAINT fk_Cod_Disciplina_Aluno FOREIGN KEY (Cod_Disciplina) REFERENCES Disciplina (Cod_Disciplina)
);

CREATE TABLE Historico (
 Cod_Historico INT PRIMARY KEY AUTO_INCREMENT,
 RA INT NOT NULL,
 Data_Inicio DATE NOT NULL,
 Data_Final DATE,
 CONSTRAINT fk_Cod_RA FOREIGN KEY (RA) REFERENCES Aluno (RA)
);

CREATE TABLE Disc_Hist (
 Cod_Historico INT NOT NULL,
 Cod_Disciplina INT NOT NULL,
 Nota INT,
 Frequência INT,
 PRIMARY KEY (Cod_Historico, Cod_Disciplina), 
 CONSTRAINT fk_Cod_Historico FOREIGN KEY (Cod_Historico) REFERENCES Historico (Cod_Historico),
 CONSTRAINT fk_Cod_Disciplina_Hist FOREIGN KEY (Cod_Disciplina) REFERENCES Disciplina (Cod_Disciplina)
);

CREATE TABLE Tipo_Telefone(
 Cod_Tipo_Telefone INT PRIMARY KEY AUTO_INCREMENT,
 Tipo_Telefone VARCHAR(8)
);

CREATE TABLE Telefones_Aluno (
 Cod_Telefones_Aluno INT PRIMARY KEY AUTO_INCREMENT,
 RA INT NOT NULL,
 Cod_Tipo_Telefone INT NOT NULL,
 Num_Telefone VARCHAR(20) NOT NULL,
 CONSTRAINT fk_Cod_RA_Tel FOREIGN KEY (RA) REFERENCES Aluno (RA),
 CONSTRAINT fk_Cod_Tipo_Telefone FOREIGN KEY (Cod_Tipo_Telefone) REFERENCES Tipo_Telefone (Cod_Tipo_Telefone)
);

CREATE TABLE Tipo_Logradouro (
 Cod_Tipo_Logradouro INT PRIMARY KEY AUTO_INCREMENT,
 Tipo_Logradouro VARCHAR(11)
);

CREATE TABLE Endereco_Aluno (
 Cod_Endereco_Aluno INT PRIMARY KEY AUTO_INCREMENT,
 RA INT NOT NULL,
 Cod_Tipo_Logradouro INT NOT NULL,
 Nome_Rua VARCHAR(50) NOT NULL,
 Num_Rua INT NOT NULL,
 Complemento VARCHAR(20) NULL,
 CEP VARCHAR(8) NOT NULL,
 CONSTRAINT fk_Cod_RA_End FOREIGN KEY(RA) REFERENCES Aluno (RA),
 CONSTRAINT fk_Cod_Tipo_Lougradouro FOREIGN KEY(Cod_Tipo_Logradouro) REFERENCES Tipo_Logradouro (Cod_Tipo_Logradouro)
);

Inserindo dados nas tabelas

Após criarmos as tabelas iremos carregá-las com alguns dados para que seja possível realizar testes no banco de dados. Insira registros usando os códigos a seguir (você pode inserir mais registros, se assim o desejar):

-- Carga de Dados para Testes
INSERT INTO Departamento (Nome_Departamento)
VALUES
('Ciências Humanas'),
('Matemática'),
('Biológicas'),
('Estágio');

INSERT INTO Professor (Nome_Professor, Sobrenome_Professor, Status_Professor, Cod_Departamento)
VALUES
('Fábio', 'dos Reis', 0, 2),
('Sophie', 'Allemand', 1, 1),
('Monica', 'Barroso', 1, 3);

INSERT INTO Curso (Nome_Curso, Cod_Departamento)
VALUES
('Matemática', 2),
('Psicologia', 1),
('Análise de Sistemas', 2),
('Biologia', 3),
('História', 1),
('Engenharia', 2);

INSERT INTO Turma (Cod_Curso, Periodo, Num_Alunos, Data_Inicio, Data_Fim)
VALUES
(2, 'Manhã', 20, '2016-05-12', '2017-10-15'),
(1, 'Noite', 10, '2014-05-12', '2020-03-05'),
(3, 'Tarde', 15, '2012-05-12', '2014-05-10');

INSERT INTO Disciplina (Nome_Disciplina, Cod_Departamento, Carga_Horaria, Descrição, Num_Alunos)
VALUES
('Raciocínio Lógico', 2, 1200, 'Desenvolver o raciocínio lógico', 50),
('Psicologia Cognitiva', 1, 1400, 'Entender o funcionamento do aprendizado', 30),
('Programação em C', 2, 1200, 'Aprender uma linguagem de programação', 20),
('Eletrônica Digital', 2, 300, 'Funcionamento de circuitos digitais', 30);

INSERT INTO Aluno (Nome_Aluno, Sobrenome_Aluno, CPF, Status_Aluno, Cod_Turma, Sexo, Cod_Curso, Nome_Pai, Nome_Mae, Email, Whatsapp)
VALUES
('Marcos', 'Aurelio Martins', 14278914536, 1, 2, 'M', 3, 'Marcio Aurelio', 'Maria Aparecida', 'marcosaurelio@gmail.com', 946231249),
('Gabriel', 'Fernando de Almeida', 14470954536, 1, 1, 'M', 1, 'Adão Almeida', 'Fernanda Almeida', 'gabrielalmeida@yahoo.com', 941741247),
('Beatriz', 'Sonia Meneguel', 1520984537, 1, 3, 'F', 3, 'Samuel Meneguel', 'Gabriella Meneguel', 'batrizmene@hotmail.com', 945781412),
('Jorge', 'Soares', 14223651562, 1, 3, 'M', 4, 'João Soares', 'Maria Richter', 'jorgesoares@gmail.com', 925637857),
('Ana Paula', 'Ferretti', 32968914522, 1, 3, 'F', 5, 'Marcio Ferretti', 'Ana Hoffbahn', 'anapaulaferretti@hotmail.com', 974267423),
('Mônica', 'Yamaguti', 32988914510, 1, 2, 'F', 6, 'Wilson Oliveira', 'Fernanda Yamaguti', 'monyamaguti@outlook.com', 932619560);

INSERT INTO Aluno_Disc (RA, Cod_Disciplina)
VALUES
(3, 1),
(1, 2),
(2, 3),
(4, 3),
(5, 4),
(6, 1);

INSERT INTO Curso_Disciplina(Cod_Curso, Cod_Disciplina)
VALUES
(1, 1),
(2, 2),
(3, 3),
(6, 4);

INSERT INTO Prof_Disciplina(Cod_Professor, Cod_Disciplina)
VALUES
(2, 1),
(1, 2),
(3, 3),
(2, 4);

INSERT INTO Historico (RA, Data_Inicio, Data_Final)
VALUES
(2, '2016-05-12', '2017-10-15'),
(3, '2014-05-12', '2020-03-05'),
(1, '2010-05-12', '2012-05-10');

INSERT INTO Tipo_Logradouro (Tipo_Logradouro)
VALUES
('Rua'),
('Avenida'),
('Alameda'),
('Travessa');

INSERT INTO Endereco_Aluno (RA, Cod_Tipo_Logradouro, Nome_Rua, Num_Rua, Complemento, CEP)
VALUES
(2, 1, 'das Giestas', 255, 'Casa 02', 02854000),
(3, 3, 'Lorena', 10, 'Apto 15', 02945000),
(1, 2, 'do Cursino', 1248, '', 0851040),
(4, 1, 'das Heras', 495, '', 03563142),
(5, 3, 'Santos', 1856, '', 04523963),
(6, 4, 'Matão', 206, '', 04213650);

O vídeo a seguir mostra o processo de criação e carga dessas tabelas no banco, que batizamos de db_Faculdade:

Na próxima parte da lição iremos realizar uma série de testes no banco, criando diversas consultas que envolvam todas as tabelas criadas.

O post Modelagem de Dados – Implementação do Banco de Dados do Projeto Prático apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.