BD Essencial - Conceitos Gerais

<img src="https://i.imgur.com/D01Fpky.png" alt="" title="Entre no nosso site e veja nossos cursos"> <h1> <img class="emoji" alt="" src="https://image.flaticon.com/icons/png/128/2906/2906274.png"> BD Essencial - Conceitos Gerais </h1> O objetivo desse curso é capacitar o aluno a entrar no mercado de trabalho executando as atividades primordiais que são solicitadas no desenvolvimento, manutenção, ou atualização de bancos de dados dos mais diferentes tipos de sistemas. Focamos na execução, e não em criação de diagramas - atividade essa que é desenvolvida por profissionais mais experientes. Nas nossas prieiras aulas, utilizamos o Gerenciador de Bancos de Dados Relacionais MySQL nesse nosso curso de Banco de Dados Essencial, porque essa ferramenta é gratuita e de fácil utilização - entretanto, todo o nosso conteúdo pode ser aplicado em qualquer Gerenciador de Bancos de Dados Relacionais, apenas com algumas mínimas diferenças. Na segunda parte do curso, utilizamos o Gerenciador de Bancos de Dados Relacionais PostgreSQL. <h2>Conceitos Gerais</h2> Primeiramente, precisamos abordar os principais conceitos de nosso objeto de estudo: <ul> <li>Banco de Dados Relacional: é um BD feito seguindo o modelo de entidades e relacionamentos, criado na segunda metade da década de 1970;</li> </ul> <ul> <li>Entidades: são as tabelas do banco de dados que contém os dados que concebemos como necessários ao nosso negócio e ao seu funcionamento;</li> </ul> <ul> <li>Relacionamenos: são tabelas criadas com o principal objetivo de realizar a ligação entre tabelas diferentes para armazenar dados que, se fossem armazenados em entidades, deixariam os bancos de dados lentos e ocupando um espaço em disco muito maior.</li> </ul>   <h3>Exemplo de Relacionamento</h3>: Na figura abaixo, vemos que o relacionamento ItemPedido, relaciona um produto e um pedido através de dados dessas duas tabelas, no caso id_Pedido e id_Produto, e adiciona alguns dados pertinentes ao pedido, como a quantidade de cada item. Em amarelo, em todas as tabelas, representamos outros campos que elas teriam num sistema real. [Para simplificarmos, nesse momento, não discutimos sobre como deveria ser a chave primária do relacionamento ItemPedido] ![](https://i.imgur.com/S5lBvgY.jpg) <h4>Chave Primária</h4> Cada registro, ou seja cada linha em cada tabela de um banco de dados, precisa de um campo, ou seja de uma coluna, que identifique aquele registro de forma única. Por exemplo, cada um de nós possui um CPF, que nos identifica como pessoa física - dessa forma, duas pessoas podem ter o mesmo nome, mas seus CPFs serão diferentes. <h4>Chave Estrangeira</h4> Uma chave é chamada de chave estrangeira quando ela é um dado que veio de uma outra tabela. No caso do exemplo da figura abaixo, as chaves estrageiras seriam id_Pedido e id_Produto, no relacionamento ItemPedido, ou seja, esses dados foram importados de outras tabelas, no caso, das tabelas Produto e Pedido. ![](https://i.imgur.com/S5lBvgY.jpg) <h2> Normalização em Bancos de Dados </h2> Normalização é o processo de criar e modelar o banco de dados projetando a forma como as informações serão armazenadas a fim de eliminar, ou pelo menos minimizar, a redundância de dados entre as tabelas do banco. Tal procedimento é feito a partir da identificação de uma anomalia em uma ou mais tabelas, decompondo-as em tabelas melhor estruturadas. <h3> Primeira Forma Normal </h3> Dizemos que uma tabela se encontra a 1ª forma normal, quando ela não tem nenhum atributo que contenha uma lista de dados. O exemplo clássico é o campo "telefones", onde haveria vários telefones de contato, separados por vírgula. Como veremos, o procedimento é o de criar um relacionamento contendo, por exemplo, id_Cliente e um número de telefone. Assim, um mesmo id_Cliente apareceria várias vezes, mas o campo telefone teria como conteúdo apenas um dado e não uma lista. Devemos adotar a mesma estratégia quando tivermos um atributo multivalorado, como endereço. Endereço não é um atributo isolado - ele pode ser decomposto em logradouro, CEP, bairro, cidade e estado. Também devemos criar um relacionamento para armazenar esses dados, como veremos mais adiante. <h3> Segunda Forma Normal </h3> Dizemos que uma tabela está na segunda forma normal, quando ela está na 1º forma normal, e todos os seus dados dependem apenas da chave primária da tabela. Na figura abaixo, os dados da tabela devem ser dependentes apenas da chave primária, que é a de locação de filme. O título do filme deve ficar na tabela que contém os dados do filme e não os dados da locação do filme. ![](https://i.imgur.com/W3MtNys.jpg) <h3> Terceira Forma Normal </h3> Uma tabela que está na 3ª forma normal, precisa estar na 1º e na 2ª formas normais. Identificamos uma tabela como não sendo da 3ª forma normal quando ela possui uma relação 1-1 "dentro dela", ou seja, quando ocorre uma redundância de dados em função de uma dependência entre esses dados e um campo não-chave. O exemplo clássico é o da tabela Carro. Cada carro tem apenas um fabricante, mas se registrássemos os dados do fabricante na tabela Carro, todos esses dados iriam aparecer sempre que um carro fosse daquele fabricante: redundância de dados em função de uma dependência entre esses dados e um campo não-chave - no caso, o campo fabricante. A solução para isso é criar um Relacionamento 1-1 entre a tabela Carro e a tabela Fabricante - onde cada carro teria um id_Fabricante. <h3> Quarta Forma Normal </h3> Uma tabela que está na 4ª forma normal, precisa estar na 1º, na 2ª, e na 3ª formas normais. Identificamos uma tabela como não sendo da 4ª forma normal quando ela possui uma [ou mais] relações 1-n "dentro dela", ou seja, quando ocorre mais de uma redundância de dados em função de uma dependência entre esses dados e um campo não-chave. O exemplo clássico seria o de uma tabela contendo dados de música, intérprete e CD. Não apenas uma música pode ser gravada por mais de um intérprete, como também pode aparecer em mais de um CD, e finalmente, pode aparecer em mais de um CD de um mesmo intérprete. A solução é criarmos dois relacionamentos 1-n. Música relacionando-se com Intérprete em um relacionamento; e música se relacionando com CD em outro. Minimizando as redundâncias de dados. ![](https://i.imgur.com/0iq1yAa.jpg) ![](https://i.imgur.com/X6c0elv.jpg) <h3> Tipos de Dados Numéricos do MySQL </h3> Na tabela abaixo vemos os tipos da dados numéricos aceitos no MySQL. Utilizamos, BIT ou TINYINT(1) para armazenar um campo booleano. Além dessa situação, os mais utilizados são TINYINT, INT, e DOUBLE. Por padrão, os campos admitem números com sinal, portanto, o padrão [default] é SIGNED. ![](https://i.imgur.com/ctbQVW0.png) Com esses conceitos preliminares, já podemos abrir o MySQL e começar nossos trabalhos.  <blockquote style="border-left-color: red;"> Prof Fernando Gomes - fernandojnr@gmail.com</blockquote> <div class="alert alert-info"> <blockquote style="border-left-color: blue;"> E.B. Cursos https://www.cursoseb.com.br/ E.B. Cursos EAD https://edsonbelemtreinamento.com.br/ead/ </blockquote> </div>