Green - Módulo

Tecnologia da Informação

Olá, aluno(a) do EmÁudio, neste módulo vamos estudar: Teoria da aula; Relações; Chaves; Relacionamentos; Integridade; Views; As 12 Regras de CODD; Álgebra Relacional; Normalização; E por fim, temos aquele Resumão para você fixar o conteúdo.

Vamos começar?

Professor: Arthur Mendonça
Narrador: Audren Silva
Duração: 2 horas 1 minuto 14 segundos

MÓDULO 02

Modelo Relacional de Dados

Tecnologia da Informação EmÁudio: Teoria da AulaOlá, bem-vindo a mais um módulo de tecnologia da informação. Sempre um prazer ter você por aqui. Tá bom?Vamos começar nossos estudos pela teoria combinado? Presta atenção então hein. Aperta o play, vamos lá. Jovem, um banco de dados como sabemos, né, é uma coleção de dados relacionados. Quando se trata de bancos de dados, algo que devemos ter em mente é que esses sistemas podem ter diferentes organizações, a depender do modelo de SGB adotado. Esse modelo está bem relacionado ao projeto lógico do banco de dados, já que esse projeto deve conter detalhes a respeito de como os dados estarão dispostos no SGBD. Tá bom?Há vários modelos de SGB existentes, como o hierárquico, o orientado a objetos, o modelo em rede e o relacional. Em cada um deles, para você ter uma ideia, os dados ficam organizados em estruturas com características distintas dos demais. Falaremos do modelo relacional. O modelo relacional foi introduzido por um americano chamado "Ted" Codd em 1970 e rapidamente ganhou popularidade, sendo hoje a opção mais tradicional quando se trata de armazenar dados operacionais das organizações. Esse modelo de dados pessoal é relativamente simples, tem uma forte fundação matemática, baseando-se em coisas complicadas como teoria dos conjuntos e lógica de predicados para formalizar os seus conceitos básicos. Para fins de concurso e para trabalhar com bancos de dados na prática, né, você não precisa entender completamente todos esses conceitos. Então vamos procurar simplificar sempre que possível. Tá legal? Fique tranquilo.Gente, podemos dizer que o modelo relacional apresenta três elementos marcantes. Vamos a eles: relações, restrições de integridade e operadores relacionais. As relações são estruturas similares a tabelas, que são as estruturas que armazenam os dados. Sabe? Restrições de integridade são o conjunto de regras que ditam o que essas tabelas podem conter e como elas se relacionam. E operadores relacionais, turma, são as operações matemáticas que servem de base para a manipulação e extração dos dados. Fica de boa, porque nós iremos falar sobre todos esses elementos ao longo desse módulo.Vamos iniciar descrevendo o que é uma relação, a estrutura que dá o nome ao modelo relacional e quais são seus componentes.Durante os nossos áudios é importante que você se lembre que o modelo relacional é um modelo teórico, tá pessoal, que serve de base para a criação de bancos de dados relacionais. Assim, alguns aspectos e propriedades que iremos apresentar se aplicam ao modelo relacional, o modelo teórico formal matemático, mas não necessariamente aos SGBDs que se baseiam nesse modelo. Toda vez que houver uma divergência entre teoria e prática, eu vou chamar sua atenção e explicar da melhor forma que puder. Tá ok? No próximo em áudio, então começaremos a pôr a mão na massa, combinado?Então, até daqui a pouco.

01 - Teoria da aula

Tecnologia da Informação EmÁudio: Relações - Parte 1Fala, galera. Bora começar a brincadeira? Então, hora de falarmos sobre as relações. Que tal? Ouvidos bem abertos, foco e vamos juntos.Jovem, os bancos de dados relacionais são exemplos de coleções de dados estruturados, né? Isso acontece porque os dados são armazenados em estruturas fixas que seguem um esquema pré-definido. No caso dos bancos de dados relacionais, essa estrutura é a relação. Uma relação armazena dados que dizem respeito a um mesmo conceito ou entidade. Por exemplo, em uma relação chamada pessoas, podemos ter vários dados que dizem respeito às pessoas que se quer representar no banco de dados. Podemos representar informalmente uma relação como uma tabela, ou seja, uma estrutura bidimensional composta por linhas e colunas. De fato, muitas provas de concurso não farão muita distinção entre os termos "relação" e "tabela", então, salvo exceções, você poderá considerar ambos os termos como equivalentes. Quando colocamos a relação nesse formato de tabela, cada linha é chamada de dupla e cada coluna corresponde a um atributo. As duplas irão caracterizar as ocorrências do que está sendo representado na relação, enquanto os atributos irão representar as características relativas a essa coisa que está sendo representada. Por exemplo, turma, em uma tabela que representa pessoas, cada dupla diz respeito a uma pessoa e cada atributo é uma característica dessa pessoa. Perceba então que é uma estrutura muito simples, parecida com uma planilha qualquer de dados. Imagino que você tenha tido contato com tabelas em vários momentos da sua vida. Por esse e outros motivos, o modelo relacional é tão popular, pois sua estrutura básica de armazenamento é familiar a maioria das pessoas.Como já conversamos, pessoal, o modelo relacional é baseado em fundações matemáticas, ou seja, ele pode ser definido em torno de conceitos e teorias dessa área. Formalmente falando, uma relação não é exatamente uma tabela, mas pode ser definida como um conjunto não ordenado de duplas. Grave essa definição, ok? Pois ela é cobrada em prova.Então vem comigo, repete aqui: uma relação é um conjunto não ordenado de duplas. Vamos pensar um pouco sobre essa definição, pois isso vai te ajudar a entender algumas propriedades que veremos mais para frente.Gente, na matemática, um conjunto é uma coleção de elementos distintos. Esses elementos podem ser qualquer coisa, como números, letras, formas ou até mesmo outros conjuntos. Em um conjunto, os seus elementos não estão ordenados de nenhuma forma. Dessa maneira, se temos dois conjuntos com os mesmos elementos dispostos de forma diferente um do outro, eles podem ser considerados o mesmo conjunto. Ou seja, galera, se temos um conjunto de números A igual a um, dois e três e o conjunto B igual a três, dois e um, podemos dizer que A e B são iguais, já que têm os mesmos elementos, os valores um, dois e três. Deu para entender? Então vamos em frente.Pessoal, como já dissemos, uma relação é nada mais nada menos que um conjunto no qual seus elementos são as duplas. Nesses conjuntos, a ordem dos elementos não é importante. Já deu para perceber, né? O mesmo acontece nos SGBDs que adotam o modelo relacional. A ordem das linhas de uma tabela do banco de dados não é relevante. Assim, você pode consultar os dados de uma mesma tabela em vários ordenamentos diferentes, mas a tabela continua sendo a mesma. Por exemplo, uma tabela de pessoas pode ter seus dados ordenados por ordem alfabética de nomes, por ordem de idade, por ordem alfabética de sua cidade, entre outras possibilidades.Dessa introdução, podemos concluir o seguinte: as relações são as estruturas que armazenam dados no modelo relacional, geralmente representadas como tabelas em provas e nos SGBDs. Outra coisa: uma relação pode ser definida formalmente como um conjunto não ordenado de duplas distintas entre si. Como conjuntos não seguem nenhuma ordenação específica, duas relações compostas pelo mesmo conjunto de duplas serão sempre a mesma relação, independentemente da maneira que suas duplas são ordenadas. Vem cá, turma. Cola o ouvidinho aqui? Você pode ter percebido que as relações em um modelo lógico relacional costumam ser representações das entidades do modelo conceitual. No modelo conceitual que deu origem ao modelo da tabela que te falei, muito provavelmente havia uma entidade chamada pessoa com os atributos CPF, nome, data de nascimento. No entanto, é importante que você saiba que essa correspondência entre entidade do modelo conceitual e relação no modelo lógico relacional não é uma correspondência exata.No processo de transformação do modelo conceitual em um modelo lógico, pode haver a criação de tabelas que não estavam previstas como entidades no modelo conceitual e determinadas entidades que existiam no modelo conceitual podem não ser representadas em uma tabela própria no modelo relacional. Quer dizer, há uma série de técnicas nessa transformação do projeto conceitual em lógico que vão ditar como esse processo vai acontecer. Entendeu, turma? Nós veremos algumas delas ao longo dos nossos estudos, pode deixar. Assunto entendido até aqui? Áudio que vem nós falaremos um pouco mais das duplas. Tá legal? Então não me abandone, hein? Te espero lá. Abraço! Até o próximo áudio.

02 - Relações - Parte 1

Tecnologia da Informação EmÁudio: Relações - Parte 2Olá, tudo certo? Vamos aprender mais um pouquinho sobre as duplas? Aumenta o som aí e vem comigo.No áudio passado, turma, nós definimos que uma relação é um conjunto não ordenado de duplas. Tá lembrado? Agora, nos resta definir formalmente o que são essas duplas.Vamos lá, então. Para continuar as nossas explicações vamos considerar novamente a relação de exemplo que trouxemos na aula passada. Vamos colocar a relação no formato de tabela, cada linha chamada de dupla e cada coluna corresponde a um atributo. Ok?No exemplo que demos no em áudio passado, em uma tabela que representa pessoas, cada dupla diz respeito a uma pessoa e cada atributo é uma característica das pessoas. Quando representamos a relação nesse formato de tabela, cada uma das duplas fica disposta em uma linha de tabela. Essas linhas são frequentemente chamadas de registros, tá?Quando estamos falando do contexto mais prático do banco de dados do SGBD mesmo, sabe? E não apenas do modelo formal.Então, turma, imagine que no nosso exemplo temos três duplas. A primeira traz dados a respeito da pessoa chamada José da Silva, a segunda a respeito de Maria do Carmo e a terceira de João Cavalcanti.Pessoal, todos os dados em uma mesma linha, o CPF, o nome, a data de nascimento e a cidade pertencem a uma mesma pessoa. Tá bem?Formalmente, as duplas podem ser definidas como sendo os conjuntos de valores de atributos que compõem uma relação. Se fôssemos organizar essas duplas da relação que acabei de falar no formato de conjunto, ficaria da seguinte maneira: - Dupla um: CPF 204 776, nome José da Silva, Data de nascimento 1º de Maio de 1990, cidade Rio de Janeiro. - Dupla dois: CPF 123 980, nome Maria do Carmo, Data de Nascimento 20 de Fevereiro de 1985, Cidade São Paulo. - Dupla três: CPF 450 689, nome João Cavalcanti, Data de Nascimento 7 de Outubro de 1979, Cidade Recife.Agora só note que uma dupla, a exemplo de uma relação, também é um conjunto. Isso implica dizer que as propriedades dos conjuntos também se aplicam às duplas.As propriedades das duplas que costumam ser cobradas em prova são aquelas definidas por um autor chamado C. J. Date, que também participou da elaboração e desenvolvimento do modelo relacional junto com o COD.Memorize essas propriedades então, pois elas costumam ser cobradas em concursos. Vou passar pra você. Vamos bater um papo, tá, sobre essas propriedades e eu vou te ajudar fazendo alguns comentários sobre cada uma delas para que você possa compreender melhor o espírito de cada uma, vamos lá.Número um: Toda dupla tem somente um valor, turma, para cada um desses seus atributos. A Primeira propriedade é a propriedade da Atomicidade dos atributos que diz que cada dupla tem um só valor para atributo. Isso quer dizer, por exemplo, que uma pessoa representada em uma só dupla da nossa relação de exemplo não poderia ter dois CPFs ou dois nomes, concorda, nem ter uma ausência de valor para sua cidade ou data de nascimento. Então, cada dupla tem exatamente um valor para os atributos, nem mais nem menos. Número dois, gente: Não há ordenação da esquerda pra direita nos componentes de uma dupla, então, oh, em relação a essa segunda característica a que trata da ordenação dos componentes de uma dupla, você já conhece a propriedade dos conjuntos matemáticos de não terem ordenação entre seus valores, não é? Assim, no modelo relacional, formal, teórico, né, realmente não haverá ordenação dentro dos componentes das duplas. Jovem, presta atenção agora em mim, se liga aqui, oh, se liga na divergência. Na prática, a história é outra, tá? Por razões práticas, a ordem das colunas definidas em um SGBD tem uma certa relevância. Vou explicar. Determinados comandos da linguagem SQL, linguagem de programação utilizada para interagir com os SGBDs relacionais, vão ter comportamentos diferentes de acordo com a ordem em que as colunas da tabela foram definidas. Nesse caso, você deve sempre avaliar o contexto da questão. Se a questão está falando de ordenação de componentes de uma dupla, o examinador está tratando da teoria do modelo relacional formal. Então, é seguro marcar que não há ordenação. Já presta atenção. Já se ele vier falar de colunas de uma tabela ou de SGBD, você vai ver que se trata da prática. Então, há sim uma certa relevância na ordem das colunas, ok? Conseguiu entender? Posso continuar? Então vem comigo.Número três: Todo subconjunto de uma dupla é uma dupla. Como assim, professor? Ouve só. Em relação à terceira propriedade, não há grandes comentários a se fazer, tá. Ela somente diz que se você extrai somente um determinado subconjunto de elementos de uma dupla, esse subconjunto também é considerado uma dupla. Só que isso não faz muito sentido na prática, né? Então essa propriedade não tem muito efeito em SGBDs. Fechou?Agora, número quatro, turma. O grau de uma dupla varia de zero a n. Quer dizer, por fim, a quarta propriedade trata da propriedade do grau das duplas, que é dado pela quantidade de elementos que a compõem, correto? Como cada dupla de uma relação tem exatamente um valor para cada atributo da relação, o grau da dupla e o grau da relação é o mesmo. Por exemplo, pessoal, a nossa relação de exemplo chamada pessoas tem quatro atributos, né? Então suas duplas também terão quatro valores. O grau das duplas e da relação será quatro. Olha a divergência aí de novo, né? Se J. Date diz que o grau de uma dupla pode variar de zero a n, ou seja, uma dupla pode não ter nenhum valor, percebeu? Isso vale para o modelo relacional formal. Só que isso não faz sentido algum na prática, pois se uma tabela de um SGBD não tem nenhuma coluna, ela não pode conter nenhum dado e de que nos serve uma tabela que não contém dados, não é mesmo? Por esse motivo, na prática, os SGBDs não costumam permitir que se crie uma tabela sem que ela tenha pelo menos uma coluna. Essa divergência não costuma ser muito explorada em prova, então só fique ciente que ela existe e adote o seguinte entendimento: Se a questão perguntar se o grau de uma dupla pode variar de zero a N, você pode considerar o item correto, ok? Se perguntar se existem tabelas sem colunas em um SGBD, você pode considerar incorreto.Vamos lá, resumindo as quatro propriedades pra você. Toda dupla contém exatamente um valor para cada um de seus atributos. Não há ordenação da esquerda para a direita nos componentes de uma dupla. Todo subconjunto de uma dupla é uma dupla. O grau de uma dupla varia de zero a N. O grau é a quantidade de atributos que compõem a dupla, conseguiu me acompanhar? Maravilha. Finalizamos então aqui as duplas. No próximo em áudio, iremos falar dos atributos. Até daqui a pouquinho.

03 - Relações - Parte 2

Tecnologia da Informação EmÁudio: Relações - Parte 3E aí, pessoal, beleza? Bora aprender mais um pouquinho? Sorriso no rosto então e som na caixa. Hora de falar dos atributos, não é mesmo? Bem, tendo em mente que uma relação é um conjunto não ordenado de duplas e uma dupla é um conjunto dos valores dos atributos, resta falarmos um pouco mais a respeito sobre esse último elemento, os atributos.Gente, cada atributo em uma relação tem um nome único. Isso implica dizer que não podemos ter duas colunas em uma mesma tabela com o mesmo nome em um SGBD relacional. O motivo é muito tranquilo de se entender, tá? Pois em um SGBD sempre fazemos referência a um atributo pelo seu nome. Por exemplo, quando você vai consultar dados em um SGBD relacional através da linguagem SQL, você precisa dizer ao SGBD qual ou quais atributos da tabela em questão você quer ter acessados. Então, você constrói um comando que diz algo como "me retorne o valor do atributo CPF para a pessoa José da Silva" ou "retorne o valor do atributo data de nascimento para a pessoa Maria do Carmo". Então, turma, nesse cenário, se você tivesse dois atributos chamados CPF ou data de nascimento dentro de uma mesma relação, o SGBD não iria saber qual dos dois retornar. Não há problema, no entanto, em atributos de relações diferentes terem o mesmo nome entre si, tá legal.Vamos agora ver quais são alguns tipos de atributos existentes que têm algumas particularidades, tá, na hora de representar um SGBD relacional. Vamos começar então pelos atributos opcionais. Quando estudamos a modelagem conceitual, observamos que existe um tipo de atributo considerado opcional, ou seja, aquele atributo que não precisa ter um valor para todas as ocorrências da entidade. Em um SGBD relacional, se um determinado atributo, como data de nascimento da tabela pessoa, é opcional, isso significa que nem toda pessoa representada nessa tabela precisa ter um valor para esse atributo. Algumas pessoas, portanto, podem simplesmente não informar a data de nascimento no ato do seu cadastro nessa base. Só que você viu nas propriedades das duplas, né, que cada dupla tem exatamente um valor para cada atributo, não é mesmo? Então isso pode ter te causado algumas dúvidas a respeito de como faremos para representar aqueles atributos que são opcionais e não têm valores. A resposta é a existência de um valor especial, turma.O valor null ou nulo. Um valor nulo é um valor especial que não tem nenhum tipo de dados, ou seja, não podemos dizer que ele é um atributo textual, numérico, de data, ou etc., e que representa basicamente uma ausência de valor. Entende?Então, toda vez que tivermos o caso em que um atributo é opcional e precisamos representar essa ausência de valor para algum registro, não vamos simplesmente deixar esse campo em branco, já que toda dupla deve ter exatamente um valor para cada atributo. Devemos utilizar esse valor nulo. Grave isso. Entendidos os atributos opcionais?Vamos então para os próximos, os atributos multivalorados. Bom, no modelo conceitual, atributos multivalorados são aqueles que possuem mais de um valor para uma mesma ocorrência da entidade. Como é que é isso, professor? Para exemplificar esse tipo de cenário comumente se usa o exemplo do atributo telefone, pois é comum que uma mesma pessoa tenha múltiplos números de telefone associados. Só que, por culpa da propriedade da atomicidade dos atributos, nós não podemos representar em uma mesma dupla os vários valores de um atributo multivalorado, já que cada dupla só tem um valor por atributo em um SGBD, na prática, né, é a mesma coisa. Não tem como você ter mais de um valor para uma mesma coluna em uma mesma linha de uma tabela. Na prática, pessoal, a representação de um atributo multivalorado requer que se crie uma tabela auxiliar para guardar os múltiplos valores desse atributo, criando-se um relacionamento para ligar essa tabela auxiliar com a tabela original. Nesse relacionamento, uma mesma pessoa pode ter nenhum ou vários telefones associados. Enquanto um telefone está associado exclusivamente a uma pessoa. Essa ligação que representa os relacionamentos nos SGBDs relacionais é realizada por algum atributo que tenha valores em comum entre as duas tabelas. No caso desse exemplo, o campo CPF pessoa na tabela telefones irá conter o valor do CPF da pessoa à qual aquele telefone corresponde. Um mesmo cliente identificado pelo seu CPF pode possuir mais de um telefone, certo, sem que isso quebre a regra da atomicidade, pois cada número está registrado em uma linha diferente dessa nova tabela, daí quando precisarmos consultar o número ou os números de telefone de uma determinada pessoa é só procurar pelo seu CPF na tabela de telefones que serão retornados todos os números correspondentes.Conseguiu entender? Vamos em frente então, turma.Atributos compostos. Além dos atributos multivalorados, existem os atributos compostos, que são aqueles que são compostos por várias partes distintas. O exemplo mais comum desse tipo de atributo é o endereço que costuma poder ser dividido em partes, como logradouro, número, complemento, cidade, e por aí vai.Nos SGBDs o que se costuma fazer é armazenar já essas partes individuais em que o atributo composto pode ser dividido, cada uma como um atributo separado, entende? Essa característica se deve a um processo que os modelos lógicos passam chamado normalização, mas vamos falar sobre isso depois. O atributo endereço, por exemplo, pessoal, poderia ficar representado separado em quatro partes: Logradouro, número, complemento e CEP. Uma curiosidade é que um atributo pode ser ao mesmo tempo composto e multivalorado, sabia? Nada impede que isso aconteça. Esse atributo foi tranquilo, né? Hora de falar do domínio.Um detalhe em relação aos atributos é que são definidas regras que ditam os valores que eles podem assumir. Uma regra que precisa ser definida para todos os atributos em um SGBD relacional é o tipo de dados. Gente, o tipo é uma restrição que indica qual é a natureza do dado, por exemplo, se ele é um número inteiro, número decimal, cadeia de caracteres, data, dentre outras possibilidades. Uma dica, jovem, vamos lá. Atributos textuais geralmente são do tipo cadeia de caracteres. Tá? geralmente chamados de varchar ou char nos SGBDs. Uma cadeia de caracteres é simplesmente um conjunto de caracteres alfanuméricos, ou seja, esse tipo de dados comporta valores como "João da Silva", "A B c", "um, dois, três", ou mesmo valores que utilizam caracteres especiais, tipo "um dois três cifrão", "cifrão quatro cinco hashtag", "defg" maiúsculo, enfim.Outras regras que podem ser definidas para os valores dos atributos incluem limitações sobre valores específicos. Por exemplo, vamos lá, um campo referente ao sexo biológico de uma pessoa pode ter seus valores restritos somente aos caracteres "m" ou "f". Para dar outro exemplo, se uma aplicação é destinada a registrar somente pessoas maiores de idade, pode se definir uma regra que só aceite a inserção de datas de nascimento a partir de uma data de dezoito anos atrás. Considerando essa possibilidade de impor restrições aos valores de um atributo, podemos definir o que é o domínio. Então, o domínio de um determinado atributo é simplesmente o conjunto de todos os valores possíveis para esse atributo. Muito bem, vamos lá, oh. Uma observação importante é que o valor nulo que citamos anteriormente não é parte de nenhum domínio de dados, tá legal, e não tem tipo. Devemos notar que colocar um valor nulo em uma célula de uma tabela é algo completamente diferente de colocar um valor zero para um campo numérico ou uma cadeia de caracteres vazia para um campo de tipo textual, entende? O nulo é um valor especial utilizado pelos SGBDs, utilizado para representar a ausência de valor. Então não podemos também utilizá-lo para comparar com outros valores. Por exemplo, não dá para dizer coisas como "nulo é igual a zero" "nulo é maior que um". Em ordem alfabética, "nulo" depois da letra "A" não dá, tá certo?Tranquilo até aqui, gente? Beleza! Finalizamos aqui mais um áudio do módulo dois do curso de tecnologia da informação. Áudio que vem tem mais, tá? Não me abandona, não, hein? Abraço.

04 - Relações - Parte 3

Tecnologia da Informação EmÁudio: Chaves - Parte 1E aí, jovem? Tudo certinho? Que bom! Neste áudio começaremos nossos estudos sobre as chaves. Preparado? Vamos juntos então.Como já conversamos, os SGBDs não somente gerenciam o armazenamento dos dados, mas também são responsáveis por gerenciar e definir uma série de regras para os dados. Por exemplo, através do SGBD, nós podemos definir como as tabelas ficam estruturadas e o domínio para cada atributo. Outro tipo de restrição ou regra que pode ser definido através dos SGBD são as chaves, que é isso aí. As chaves são as estruturas que permitem identificar e relacionar as tabelas. Isso é bastante importante, tá legal, pois ao entendê-las, vemos como os atributos-chave do modelo conceitual são representados no modelo lógico, e também iremos começar a entender como é possível definir os relacionamentos entre as tabelas.Para iniciar o nosso estudo das chaves, vamos primeiro imaginar um diagrama de um modelo lógico que nos permitirá ilustrar os conceitos que serão apresentados. Tá ok? E aí imaginou? Ótimo, imagine agora que esse trecho de diagrama traz diversos tipos de relacionamento e de chaves. Oh turma, vamos falar sobre cada um deles a seguir.Antes de prosseguirmos é muito importante que você memorize que não existe uma notação muito definida para representar modelos lógicos. Tá bom? Em relação aos relacionamentos as bancas também costumam utilizar as mesmas anotações do modelo conceitual para representar os conceitos de cardinalidade e participação.Agora, antes de prosseguirmos, um detalhe. No nosso Diagrama imaginário, vamos colocar dois relacionamentos entre as tabelas servidor e setor. Isso é plenamente possível, tanto na modelagem conceitual quanto na modelagem lógica relacional. Para que possamos distinguir entre os dois, vamos colocar os nomes de cada um ao lado da respectiva linha que representa o relacionamento.Em provas de concurso, turma, esse tipo de ocorrência é mais raro. Ok? Mas é importante que você saiba que é possível. Tranquilo até aqui? Muito bem, vamos em frente. Bom, vamos começar com o conceito de chave primária. Nos modelos lógicos, as chaves primárias costumam estar marcadas com as iniciais PK, PK de Prime Key ou com um pequeno ícone de chave ao lado do nome dos atributos, ok? Essas chaves, turma, estão bastante relacionadas com o conceito de atributos-chave da modelagem conceitual. Uma chave primária pode ser definida como uma escolha de um conjunto de atributos que identificam unicamente uma dupla dentro de uma relação. Esse conjunto de atributos também pode ser unitário, ou seja, somente um atributo faz parte da chave primária. Nesse caso, ela será uma chave primária simples. Já quando múltiplos atributos fazem parte da chave primária, ela é conhecida como composta. Agora, seja chave simples ou composta, o que importa mesmo é que o valor da primary key seja único dentro de uma mesma tabela, para que possa agir como um identificador de cada linha que faz parte dela. No caso de uma chave primária simples, é bem fácil de entender. Os valores do atributo que compõem a chave não poderão se repetir na relação, ok? Já no caso de uma chave composta, os valores de cada um dos atributos que fazem parte da chave primária individualmente podem se repetir, mas a composição desses atributos não pode se repetir em momento algum. Tá bom, turma? Por exemplo, imagine uma tabela com participantes da reunião. Por ora, esqueça o que essa tabela significa. A chave primária dela é composta pelos dois atributos da tabela ID Reunião e CPF Servidor.Jovem, quanto ao atributo ID Reunião separadamente, os valores podem se repetir. Em relação ao atributo CPF, servidor, é a mesma coisa, também pode se repetir. O importante em uma chave composta, é somente que todas as combinações entre os valores de ID Reunião e CPF servidor sejam únicas. Uma observação muito importante é que, apesar da chave primária poder ser composta, só existe uma chave primária por tabela. Pode parecer um pouco confuso, mas é assim que funciona. Isso acontece porque a chave primária é considerada uma regra ou restrição de integridade do SGBD e não um atributo ou um conjunto de atributos. Então, tecnicamente não podemos dizer que os atributos que fazem parte da chave primária são a chave, o correto é dizer que esses atributos fazem parte da chave. Essa é uma distinção que as bancas não costumam fazer no momento da prova. Você irá ver vários enunciados de questões dizendo, por exemplo, "O atributo ID Setor é a chave primária da tabela Setor". Ou então algo assim: "Os atributos ID Reunião e CPF servidor são a chave primária da tabela Participa Reunião", sem que isso seja considerado incorreto. Elas vão fazer isso assim. Eu só trouxe essa discussão para a nossa aula porque surgem muitas dúvidas de alunos que confundem o fato de uma chave primária ser composta com haver mais de uma chave primária por tabela, o que não pode acontecer. Tudo bem aqui? Vamos seguir. Outra questão muito importante: os atributos que compõem uma chave primária não podem assumir o valor nulo. Isso acontece porque o nulo representa uma ausência de informação, não é mesmo? Então, tecnicamente, não é possível realizar comparações com ele em um SGBD relacional. Não é possível, por exemplo, dizer que nulo é igual a nulo ou que nulo é diferente de nulo. É estranho. Eu sei, mas é assim que funciona. Tá legal? A moral da história aqui é que não conseguimos comparar nulo com nada né, nem com o próprio nulo. Não dá pra usar ele nunca numa chave primária, guarda isso. Isso porque não poderíamos dizer também que o valor nulo é igual ou diferente dos demais e, portanto, não conseguiríamos afirmar que a chave é única ou não. Tá ok? Outra característica importante é que a chave primária pode ter correspondência com algum elemento do mundo real, como o CPF, caso em que é considerado uma chave natural. A chave pode também assumir um valor aleatório gerado pelo SGBD, caso em que será chamada de surrogate key, ou chave substituta.O único propósito de uma surrogate key, ou chave substituta, é agir como chave primária. Ela não tem correspondência com algum dado do mundo real ou qualquer significado implícito, tá. Assim, ela não é considerado um atributo descritivo. Para nomear as chaves substitutas é muito comum que se use o prefixo ID de identificador antes do nome da tabela. Por exemplo, a nossa tabela reunião tem um atributo chamado ID Reunião que é uma chave primária substituta que identifica unicamente cada reunião. Deu para pegar? Show.As chaves substitutas, gente, podem ser identificadas quando não existem algum atributo natural da tabela que seja capaz de identificar unicamente cada registro mas também podem ser utilizadas em qualquer outra circunstância por decisão do projetista do banco de dados. Muitas vezes os administradores consideram mais fácil gerenciar as chaves substitutas pois seus valores são fixos, imutáveis para cada registro. E não tem associação com nenhum valor ou característica da realidade. Essas chaves substitutas muitas vezes são do tipo autoincremento. O que que é isso aí? São valores numéricos que vão sendo incrementados pelo próprio SGBD a medida que adicionamos os registros. Assim, o usuário não precisa se preocupar com os valores das chaves. Então, se a chave ID Reunião for do tipo autoincremento, o SGBD pode atribuir o valor um ao ID da primeira reunião criada. Em seguida, quando a próxima reunião for cadastrada no sistema o SGBD irá atribuir o valor ID Reunião igual a dois já que a anterior tinha sido reunião um. A terceira reunião será igual a três, a quarta quatro, a quinta cinco e assim vai embora.Assunto entendido, pessoal? Vou finalizar esse áudio para não ficar muito cansativo, tá? Aproveita aí para beber uma águinha, levantar, se alongar que é importante que já, já estou de volta. Abraço e até o próximo áudio.

05 - Chaves - Parte 1

Tecnologia da Informação EmÁudio: Chaves Parte - 2Bom dia! Boa tarde! Boa noite! Tudo certo meu jovem? Ainda não finalizamos nosso Bate-papo, né, sobre as chaves. Temos muito o que conversar ainda, tá legal? Então foco e aperta o play aí quero ouvir. Hora de falar das super chaves e das chaves candidatas. Vamos lá. Já ouviu falar nelas antes? Então vem comigo que eu te explico. Turma, na maioria dos casos, uma tabela pode ter múltiplos conjuntos de atributos que são capazes de identificar unicamente cada registro, incluindo, mas não se limitando a chave primária, tá? Esses conjuntos são conhecidos como super chaves. Não, não é o super-herói Chaves da televisão não. Como todos os registros de uma tabela são diferentes entre si. Lembra que uma relação é um conjunto de duplas distintas? Então há pelo menos uma super chave em cada tabela de um banco de dados relacional, aquela que é composta por todos os atributos da relação. Se todas as duplas são diferentes, então cada conjunto de todos os atributos logicamente será único. Não é mesmo? Só que na maioria das vezes, turma, não é necessário usar todos os atributos da relação para identificar unicamente cada dupla. Por exemplo, na tabela pessoas que já ouvimos, já falamos disso, somente a utilização do atributo CPF já era suficiente. Não é? Como nós percebemos. Então, assim, não há nenhuma necessidade de se usar todo o conjunto composto por todos os atributos CPF, nome, data de nascimento, idade como chave primária, pois só o CPF já basta. Então podemos considerar que CPF é uma chave mínima, pois é uma chave composta pela quantidade mínima de atributos possível para identificar cada atributo da relação.Ouça agora que se você pegar os conjuntos, CPF, nome, CPF, nome, data de nascimento ou CPF, nome data de nascimento e cidade todos eles são capazes de identificar unicamente cada dupla também. Os valores desses conjuntos de atributos não se repetem na relação. Tá, então vamos lá. Só que esses conjuntos serão considerados somente super chaves e não chaves mínimas, pois são, sim, capazes de identificar cada dupla, mas tem atributos desnecessários aí no meio. Percebeu? Uma vez que somente o CPF já seria suficiente. Tá conseguindo me acompanhar? Ótimo. Vamos em frente!Uma tabela pode ter mais de uma chave mínima. Vamos conferir isso. Se a tabela também tivesse uma chave substituta, como D Pessoa tanto CPF quanto ID Pessoa seriam consideradas chaves mínimas, pois tem a quantidade mínima de atributos necessários para identificar unicamente cada dupla, não apresentando nenhum atributo supérfluo desnecessário em sua composição. Essas chaves mínimas durante o projeto do banco de dados são conhecidas como chaves candidatas, pois são candidatos a ser a chave primária. Entende? Só que, como sabemos, uma tabela sempre terá somente uma chave primária, né, turma. Então iremos escolher somente uma das chaves candidatas para ser a chave primária. Então o processo de escolha da chave primária fica assim. Super chaves são todos os conjuntos de atributos que podem identificar unicamente uma dupla. Chaves Candidatas são as super chaves que são mínimas, quer dizer sem atributos desnecessários. A chave primária é escolhida dentre as chaves candidatas. Percebeu aí o processo de escolha da chave primária? Muito bem. Conseguiu entender? Ótimo. Agora que aprendemos o conceito de super chaves e chaves candidatas, vemos que nem todos os atributos que são capazes de identificar unicamente uma relação são escolhidos como chave primária. Nesse sentido, os SGBDS também permitem que se defina uma regra chamada de restrição de unicidade, chamada de UNIQUE na linguagem SQL que diz que um atributo ou um conjunto de atributos deve ter valores únicos dentro de uma tabela.Gente, essa regra, quando criada, não permite que se insira valores repetidos para esses atributos. Tá legal? A única diferença em relação aos critérios da chave primária é que essas restrições de unicidade não se preocupam em relação a valores nulos. Ou seja, os atributos com restrição unique podem assumir o valor null. Legal, então.Super chaves e das chaves candidatas. Tá tudo entendido? Ótimo, áudio que vem, nós falaremos da chave estrangeira. Fica comigo, tá? Daqui a pouquinho tem mais. Tchau, tchau.

06 - Chaves - Parte 2

Tecnologia da Informação EmÁudio: Chaves - Parte 3E aí cheguei meus concurseiros, tudo bem? Olá para todo mundo! Hora de aprender um pouco sobre a chave estrangeira. Vamos nessa? Aumenta o som aí e vem comigo.Jovem, ouve só. Em um banco de dados relacional todos os dados são representados no formato de tabelas, tá. Como já conversamos, né? Boa parte das entidades presentes no modelo conceitual viram tabelas quando passamos para o modelo lógico. Só que fica a dúvida: e os relacionamentos, como podemos fazer para representá-los? Muito bem, para começarmos a entender como os relacionamentos são representados no modelo relacional, precisamos conhecer um novo tipo de chave chamado de chave estrangeira.O objetivo desse tipo de chave aqui é basicamente possibilitar que se criem ligações lógicas entre as tabelas, permitindo a representação dos relacionamentos. As chaves estrangeiras geralmente ficam representadas nos modelos lógicos através da sigla F K (chave estrangeira em inglês).Pra você entender bem o que eu tô falando, imagine um trecho de modelo lógico, com uma tabela servidor e uma tabela setor. Quando você se deparar com uma marcação F K em um trecho de modelo lógico, entenda que um ou mais atributos da tabela compõem uma chave estrangeira.Uma chave estrangeira, gente, serve para identificar unicamente um registro em outra tabela. Isso ocorre com base na igualdade dos valores dos atributos, tá legal? Por exemplo, a chave estrangeira no atributo ID setor da tabela servidor contém valores idênticos ao atributo ID da tabela setor, permitindo que se represente o relacionamento trabalho.Assim, toda vez que o servidor tiver um valor x para o atributo ID setor, ele se ligará ao registro da tabela setor cujo valor de ID é também igual a X. Conseguiram pegar? Legal.Jovem, o que está acontecendo aí é que existe um relacionamento entre servidor e setor, dado pela chave estrangeira que liga os campos ID setor e D. Quando esses atributos tiverem o mesmo valor, os seus registros ficarão ligados entre si. Percebe?Esse ato da chave estrangeira apontar para um atributo de outra tabela é geralmente chamado de referenciar ou fazer referência. Então, a chave estrangeira presente no atributo ID Setor de servidor referencia o atributo ID da tabela Setor. Por esse motivo chamamos a tabela de onde se origina a referência de referenciada e a tabela que se destina à referência de referenciada.Mas fique ligado: uma chave estrangeira não necessariamente referencia uma chave primária. Apesar de ser o caso mais comum, a chave estrangeira pode referenciar qualquer conjunto de atributos, desde que esses também possam identificar unicamente um registro da tabela de destino. Então, turma, ao contrário das chaves primárias, uma tabela pode ter múltiplas chaves estrangeiras, já que uma mesma tabela pode participar de vários relacionamentos diferentes.Agora, na minha visão, essa diferenciação é necessária para a clareza do modelo, já que sem ela não poderíamos saber se é uma chave estrangeira composta por vários atributos, ou se são várias chaves estrangeiras compostas por um atributo cada.Na hora da prova nem sempre a banca vai fazer essa diferenciação, tá legal, mas isso não costuma ser um problema. Nas provas de concurso, as chaves estrangeiras podem ser representadas de diversas maneiras, às vezes o examinador usa o termo F K, às vezes coloca um ícone de uma chave um pouco diferente da chave primária e, às vezes, não faz diferenciação alguma dos demais atributos.Para fins de prova, o que acontece é que geralmente os nomes dos atributos são bem intuitivos e permitem identificar facilmente que são as chaves estrangeiras. Quero ouvir um exemplo? O atributo ID setor na tabela servidor obviamente referencia a tabela setor e o atributo ID reunião na tabela participa reunião obviamente referencia a tabela reunião.Os modelos ER e lógicos utilizados em questões tendem a ser relativamente simples e intuitivos, então, não acho que você terá problemas quanto a isso. Tá legal? Uma observação final é que, ao contrário da chave primária, a chave estrangeira pode, sim, assumir o valor nulo, desde que o projeto defina que a participação da entidade no relacionamento associado é parcial. Na participação parcial, determinadas ocorrências da entidade ou determinados registros da tabela no modelo lógico podem simplesmente não participar do relacionamento.No exemplo da nossa tabela, a participação de servidor no relacionamento é opcional, né? Pois um servidor pode não trabalhar em nenhum setor específico. Isso pode ocorrer com um servidor que acabou de ser nomeado e ainda está fazendo o curso de formação, e por isso ainda não tem uma lotação definida em algum setor. Nesse caso, o valor do atributo ID setor que é a chave estrangeira da tabela pode ficar nulo, uma vez que o servidor não está associado a nenhum setor, conseguiu entender? Espero que sim. Muito bem gente, oh, fico por aqui! Obrigado pela sua companhia e até mais! Tá chegando aí, o próximo áudio. Te espero lá. Tchau, tchau.

07 - Chaves - Parte 3

Tecnologia da Informação EmÁudio: Relacionamentos - Parte 1Oi! Fala, jovem. Agora é hora de falar sobre relacionamentos, vem comigo.Gente, a cardinalidade de um relacionamento diz respeito à quantidade máxima de ocorrências de uma entidade que pode estar associada a uma ocorrência da outra. Na modelagem conceitual dos bancos de dados geralmente representamos os relacionamentos em função de três tipos de cardinalidades: um para um, um para m e m para n. A maneira com que esses relacionamentos vão ser implementados em um banco de dados relacional vai variar de acordo com essa cardinalidade, claro, mas de modo geral iremos utilizar chaves estrangeiras para possibilitar a sua representação no modelo lógico.Vamos aprender um pouco sobre a modelagem do relacionamento um para um, ou seja, um dois ponto um. Na cardinalidade um para um entre duas tabelas a e b, né, temos as seguintes regras, turma. Um Registro de A referencia no máximo um registro de B; um registro de B referencia no máximo um registro de A. Como exemplo temos o relacionamento gerência entre servidor e setor. Vamos lá pra imaginação? Põe pra funcionar aí então. Imagine um diagrama E R que um funcionário só pode gerenciar um setor e um setor só pode ser gerenciado por no máximo, um funcionário mesmo cenário pode ser representado no modelo lógico relacional. Aí, nesse caso, apesar de estar usando a notação pé de galinha e não a anotação de Elmasri e Navathe para representar a cardinalidade e a participação, dá pra ver que a cardinalidade desse relacionamento é realmente um para um, pois os símbolos que ficam mais próximos das entidades são dois traços verticais, guarda isso.Se você não compreende essa anotação, sugiro verificar a aula que trata de modelagem conceitual novamente. Ok?O que nos interessa agora é ouvir nessa aula como isso fica representado nas tabelas do banco de dados? Quer um exemplo aí, para entender melhor? Vamos lá, tente visualizar duas tabelas, visualizou? Muito bem. Agora, imagine que eu omiti algumas colunas das tabelas, mas isso foi somente para não nos atrapalhar na hora da explicação. Não se preocupe muito com isso. Vamos chamar a primeira tabela de servidor e a segunda de setor. Na tabela Servidor, eu omiti o CPF do funcionário, que é um gerente e na tabela Setor, eu omiti o seu nome. Assim, sabemos que a tabela setor tem uma chave estrangeira no atributo CPF Gerente que referencia o campo CPF chave primária da tabela Servidor, para cada registro de setor irá constar no campo CPF gerente o CPF do servidor que é o gerente, né? Nenhuma grande dúvida até aqui, não é mesmo? Um detalhe é que nesse caso somente criar a chave estrangeira não seria suficiente para definir esse relacionamento como sendo um para um. Se fizéssemos somente isso, nada no SGBD impediria que dois setores tivessem valores repetidos para CPF gerente, tornando o relacionamento um para muitos. Por isso é necessário estabelecer uma outra regra além da chave estrangeira. Se dissermos ao banco de dados que os valores de CPF gerente na tabela setor devem ser únicos isso bastará para caracterizar o relacionamento como um para um. Assim, temos que utilizar uma restrição de unicidade. Dizemos ao SGBD algo como: "Veja bem, esse atributo CPF Gerente não é uma chave primária, mas também não pode ter seus valores repetidos". Na linguagem SQL, vamos criar essa condição ou restrição através de um comando chamado "UNIQUE". Nesse caso, turma, como os CPF e gerente não poderão se repetir, um gerente não poderá estar associado a mais de um setor. Pelo outro lado, como um setor só tem um campo que diz qual é o CPF do gerente, um setor também não terá como estar associado a mais de um gerente, concorda? Então está pronto, aí o nosso relacionamento um para um. Conseguiu entender? Quando a participação de ambas as entidades no relacionamento um para um é total, acontece uma situação peculiar. Nesse caso, pessoal, tanto a cardinalidade mínima quanto a máxima dos dois lados do relacionamento é um, o que significa dizer que todo o registro de A corresponde a exatamente um registro de B e vice-versa. Nesse cenário, gente, pode fazer sentido utilizar uma outra abordagem para representar esse relacionamento no modelo lógico, sem a necessidade de se utilizar chaves estrangeiras. Essa abordagem envolve mesclar as entidades A e B em uma relação única que combine todos os atributos das duas relações envolvidas. Essa abordagem aparece pouco em provas de concurso, tá bom? Então só memorize que essa possibilidade existe e siga em frente, sem maiores detalhes por aqui.Tudo bem até aqui? Beleza. Vou dar um tempo para você respirar e beber uma água, tá? Já eu volto e até o próximo áudio.

08 - Relacionamentos - Parte 1

Tecnologia da Informação EmÁudio: Relacionamentos - Parte 2Olá, jovem. Bem-vindo de volta! No em áudio passado, falamos dos relacionamentos um para um. Lembra? Bora aprender sobre os relacionamentos um para muitos? Cola em mim então. Vem cá.A gente começa desse jeito: na cardinalidade um para muitos entre duas tabelas A e B, temos as seguintes regras: um registro de A pode referenciar vários registros de B. Um registro de B referencia, no máximo, um registro de A.Podemos exemplificar como esse tipo de atributo é representado no modelo relacional, com o relacionamento trabalha entre as tabelas servidor e setor.Seguindo a lógica, sabemos que um servidor pode trabalhar em um setor, mas em um setor podem trabalhar diversos funcionários. Não é mesmo? Para representar esse tipo de relacionamento, nós iremos utilizar novamente uma chave estrangeira em uma das tabelas. No nosso exemplo, o relacionamento é possibilitado através da chave estrangeira FK1 criada no atributo setor da tabela Servidor.No caso dos relacionamentos um para muitos, a chave estrangeira deve ser posicionada na tabela do lado n do relacionamento. Aqui não faz sentido utilizar uma restrição de unicidade como fizemos no relacionamento um para um, pois a ideia é realmente permitir que os valores da chave estrangeira possam se repetir já que é um relacionamento um para muitos.Bem tranquilo o relacionamento um para muitos, não é não? Mas e os relacionamentos muitos para muitos? M dois pontos N. E aí jovem? Vem comigo que eu te explico. Na cardinalidade muitos para muitos entre duas tabelas A e B, temos as seguintes regras: um registro de A pode referenciar vários registros de B. Um registro de B pode referenciar vários registros de A. Esse tipo de relacionamento é só um pouco mais complexo de se implementar no modelo lógico, tá?Vamos adotar o exemplo do relacionamento entre servidor e reunião, em que um servidor pode participar de várias reuniões e uma reunião conta com a participação de vários servidores. No modelo lógico, o que geralmente se faz é criar uma tabela de ligação entre as duas tabelas envolvidas num relacionamento, criando dois relacionamentos um para muitos entre essa tabela de ligação e as duas tabelas envolvidas.Agora perceba que o relacionamento entre servidor e participa reunião é um para muitos, e o relacionamento entre participa reunião e reunião é muitos para um. Os dois relacionamentos um para muitos acabam permitindo a concretização do relacionamento muitos para muitos entre as duas tabelas das pontas servidor e reunião.Nesse caso, note que participa reunião tem duas chaves estrangeiras, uma apontando para a reunião e outra para o servidor. A composição dessas duas chaves estrangeiras será também a chave primária de participa reunião.Um detalhe que você deve ter percebido é que, como sabemos, um relacionamento também pode ter seus próprios atributos. Dessa maneira, podemos colocar aqueles atributos que dizem respeito ao relacionamento nessa tabela de ligação. No nosso exemplo, vamos colocar o atributo situação na tabela intermediária participa reunião. Isso porque esse atributo diz respeito ao relacionamento, ou seja, à participação de um servidor em uma reunião e não somente à reunião ou somente ao servidor.Pessoal, essa abordagem de se utilizar uma tabela intermediária pode ser utilizada para implementar relacionamentos de qualquer cardinalidade, mas é algo considerado desnecessário na maioria das vezes para os relacionamentos um para um e um para muitos. Isso ocorre porque seria necessário realizar várias operações de junção entre as tabelas para consultar os dados relacionados, além de trazer o trabalho de se manter mais uma estrutura no modelo de dados.E aí, conseguiu me acompanhar? Pegou tudo aí direitinho? Que bom! Ainda temos alguns pontos para conversar. Tá legal? Mas vou deixar para o próximo áudio, ok? Até já!

09 - Relacionamentos - Parte 2

Tecnologia da Informação EmÁudio: Relacionamentos - Parte 3 Fala, galera! Beleza? Para finalizar o assunto Relacionamentos, falta ainda batermos um papo sobre os auto relacionamentos. Então eu te convido aí a apertar o play e vem comigo. Você sabe que existem os relacionamentos recursivos, aqueles de grau um, ou seja, que envolvem apenas um conjunto de entidades. Esses relacionamentos, também conhecidos como auto relacionamentos, são representados da mesma maneira que os demais. A única diferença aqui é que a tabela referenciada e a referenciada são a mesma para relacionamentos um para um e um. Para muitos, a ideia é criar uma chave estrangeira que referencie a chave primária da própria tabela. Já no caso de um relacionamento muitos para muitos, cria-se uma tabela auxiliar que tem duas chaves estrangeiras apontando para a chave primária da tabela original. Vamos voltar para os nossos exemplos da tabela servidor que tem um auto relacionamento utilizado para representar a relação de chefia entre dois servidores. Nesse caso, gente, um servidor pode ser chefe de vários outros, enquanto pode ser chefiado por apenas um outro servidor. A chave estrangeira, que seria o CPF chefe, referencia a chave primária da própria tabela. Assim, um servidor pode referenciar um outro servidor? Tranquilo, né? Muito bem. Jovem, vou quebrar seu galho agora e vou fazer um resumo sobre esse assunto relacionamentos.Não quero que você fique com dúvidas e para você não se confundir vamos resumir as possibilidades das técnicas de modelagem lógica dos relacionamentos, ok? Vamos lá? Presta atenção aí comigo. Relacionamento um para um: chave estrangeira em uma das duas relações, melhor ser naquela que tiver participação total, tá, com restrição de unicidade. Quando a participação for total em ambos os lados, pode-se mesclar as relações em uma só. Usar tabela de ligação, tá gente?Isso tudo aí é para relacionamentos um para um. Agora, relacionamentos um para muitos: chave estrangeira do lado n do relacionamento usar tabela de ligação. Agora, relacionamento muitos para muitos: usar tabela de ligação. Somente isso. Assunto é entendido, meu jovem? Ótimo. Finalizamos então mais um em áudio por aqui. Até mais, te espero no próximo áudio.

10 - Relacionamentos - Parte 3

Tecnologia da Informação EmÁudio: IntegridadeE aí, turma? Tudo bem? Hora de falar sobre a integridade. Já ouviu falar nela? Vem comigo que eu te explico. Vamos nessa.Pessoal, a integridade de um sistema pode dizer respeito ao aspecto físico do mundo real, que diz respeito ao armazenamento dos dados em um meio físico, como em um HD ou fitas de backup. A integridade física pode ser comprometida por danos como aqueles causados por corrosão, falhas elétricas, catástrofe natural no local onde os servidores ficam, dentre outras inúmeras possibilidades.Só que esse não é o tipo de integridade que estamos buscando. A integridade, que será o objeto do nosso estudo será uma integridade lógica, ou seja, aquela que tem a ver com os aspectos do software do banco de dados, como as regras que foram definidas ao se projetar o banco de dados. Como já mencionamos em várias partes da nossa aula um banco de dados relacional possui um conjunto de regras como os dados devem estar organizados e relacionados. Essas regras que governam o armazenamento e processamento dos dados são as restrições de integridade de que iremos tratar nesta sessão.Elmasri e Navathe dividem as restrições de integridade em três categorias: restrições inerentes ao modelo ou implícitas, restrições baseadas em esquema ou explícitas e restrições semânticas, também chamadas baseadas em aplicação, regras de negócio ou integridade definida por usuário.Gente, as restrições inerentes ao modelo de dados nós já vimos quando estudamos os fundamentos do modelo relacional. Todas aquelas regras relacionadas às relações duplas e atributos que estudamos no começo da aula são restrições implícitas. Por exemplo, ao dizermos que, no modelo relacional, duas duplas não podem ser iguais, estamos expressando uma restrição inerente ao modelo relacional.Aí, jovem, as restrições semânticas também não serão alvo do nosso estudo aprofundado. Tá? Essas restrições dizem respeito às regras de negócio que não são fáceis de se implementar num banco de dados. Por exemplo, numa aplicação bancária, não cabe ao banco de dados dizer se podemos associar um cliente a um empréstimo. Quem irá calcular se o cliente pode ou não pegar um empréstimo será o sistema de aplicação do banco operado pelo atendente. Em vários desses casos, até existem funcionalidades na linguagem SQL que permitem definir essas regras, como através da utilização de estruturas chamadas gatilhos. Só que essa parte de linguagem é muito complexa, o que na maioria das vezes faz com que os desenvolvedores apliquem essas regras de negócio nos próprios programas de aplicação e não no SGBD.As restrições que vão ser do nosso maior interesse são as restrições explícitas, pois elas vão variar de acordo com o projeto do banco de dados e podem ser especificadas de diferentes maneiras pelos usuários do SGBD. Vamos lá? Pessoal, as restrições baseadas em esquema ou explícitas em um SGBD relacional, são aquelas que podem ser definidas via linguagem SQL, mais especificamente em uma sub linguagem chamada DDL. Linguagem de Definição de Dados. Segundo Elmasri e Navathe, essas restrições se dividem em restrições de domínio, de chaves, de valores nulos, de entidade e de integridade referencial.Agora, para fins de prova, penso que memorizar as restrições de integridade que vou listar a seguir é o suficiente. Tá bom? Note, inclusive, que todas elas tratam de conceitos já abordados durante a sua aula, o que vai facilitar o entendimento. Ok?A primeira restrição de integridade que vamos conversar é a integridade de entidade. Esse tipo de restrição está relacionado às regras impostas pelas chaves primárias, integridade de entidade define somente que cada chave primária deve ser única e não nula. Também é conhecida como integridade primária ou de chave primária.Segunda restrição de integridade. Vamos lá, integridade referencial. Como é que é isso aí? A integridade Referencial, turma, está relacionada ao conceito de chave estrangeira. A regra simplesmente determina que uma chave estrangeira só pode estar em dois estados, fazendo referência a um registro válido da tabela referenciada ou assumindo o valor null, caso em que o registro em questão não participa do relacionamento. Tá bom?Lembrando que esse último caso aí só é possível no caso de participação parcial da entidade no relacionamento. A ideia aqui, gente, é basicamente que uma chave estrangeira deve estar referenciando corretamente um registro da tabela referenciada ou não referenciando ninguém. Por exemplo, considere que temos a chave estrangeira Setor na tabela Servidor que referencia o campo ID da tabela Setor. Nesse caso, se existe algum valor de ID setor que não existe no campo referenciado ID, essa é uma violação à integridade referencial. Entendeu?Vamos à terceira e última restrição de integridade, a integridade de domínio, turma. O domínio é o conjunto dos valores possíveis para um determinado atributo. Tá bom? Dessa forma, a integridade de domínio determina que os valores de todas as colunas em todos os registros de um banco de dados fazem parte de seus respectivos domínios. Por exemplo, se diz que um atributo é de um tipo numérico, um registro não poderá nunca ter um valor textual para esse atributo. Dentro da integridade de domínio, temos uma subcategoria chamada integridade de vazio. O que é isso aí? Essa restrição determina se o atributo pode ou não assumir valores nulos. Conseguiu entender esse áudio? Esse em áudio foi tranquilo, né? Na próxima aula iremos estudar as views. Até lá. Abraço!

11 - Integridade

Tecnologia da Informação EmÁudio: ViewsBom dia! Boa tarde! Boa noite, meu caro aluno e minha cara aluna. Tudo certo? Bora aprender mais um pouquinho. Hora de falar sabe o que sobre as views. De que professor? Do que? Da onde? Das views, jovem.Uma das vantagens da abordagem de bancos de dados é o suporte a múltiplas visões sobre os dados. Essa característica permite que diferentes usuários tenham diferentes perspectivas sobre o mesmo conjunto de dados. Assim, determinados usuários podem ver somente parte de uma tabela, enquanto outros enxergam a tabela inteira, entendeu? Um terceiro grupo ainda poderia consultar os dados somente de forma agregada, agrupada sem visualizar todos os registros detalhados? Enfim, são inúmeras as possibilidades.Como você já ouviu aqui nas aulas a estrutura básica do banco de dados relacionais é a tabela relação. Essas tabelas ficam persistidas no banco de dados de uma forma fixa, seguindo uma estrutura pré-definida. Para podermos concretizar essa característica do suporte a múltiplas visões, ou seja, permitir que usuários do banco de dados visualizem os dados de uma ou mais tabelas de uma maneira diferente com que elas estão armazenadas nós precisamos executar consultas SQL que extraiam os dados nessas diferentes formas.Para exemplificar como isso ocorre, vamos considerar um trecho de uma tabela que contém dados sobre os servidores de um órgão. Ela tem a seguinte estrutura: CPF, nome, salário, endereço e o setor. Agora, considere que essa tabela é usada para vários propósitos. Um dos pontos centrais de se ter um banco de dados é esse mesmo permitir que vários usuários distintos, com propósitos distintos, possam acessar os dados. Um desses propósitos consiste em disponibilizar os dados no Portal da Transparência. Só que para esse fim é necessário omitir o endereço dos servidores, já que essa não é uma informação pública e sim pessoal de cada servidor. Nesse caso, pessoal, não podemos disponibilizar a tabela inteira no portal, então devemos fazer uma consulta SQL que retorne somente um subconjunto dos atributos da tabela, sem que o endereço seja retornado. A consulta seria assim: select, CPF, nome, salário, setor from servidores - não precisa decorar isso. Tá bom? Fique tranquilo.Ao executar essa consulta, o resultado seria retornado à tabela da seguinte maneira: CPF, nome, salário e setor. Nessa consulta, turma, nós não alteramos a estrutura ou o conteúdo da tabela Servidores, nem armazenamos seus resultados em local algum. A única coisa que fizemos foi extrair os dados da tabela de uma forma diferente da que estão gravadas. Omitindo a informação do endereço, percebeu? Para disponibilizar esses resultados no Portal da Transparência então poderíamos executar a consulta SQL, que mostramos copiar os resultados exibidos no SGBD e só então disponibilizá-los no portal. Mas toda vez que houvesse uma mudança nos valores dos dados da tabela, teríamos que fazer todo esse procedimento novamente, o que tornaria a atualização desse portal algo bastante trabalhoso, né? Então, como solução podemos definir uma visão no SGBD.Uma visão, do inglês view, é definida como uma tabela derivada de outras tabelas, ou seja, gente a view é uma visão diferente sobre os dados que estão armazenados em tabelas do banco de dados. Nós sempre definimos uma view a partir de uma consulta SQL. No caso do exemplo, poderíamos criar uma view chamada servidores sem endereço, por exemplo, que armazena a consulta que executamos anteriormente. Assim, toda vez que o Portal da Transparência consultar os dados da view, ela irá retornar os dados dos servidores, omitindo a informação do salário da maneira que definimos anteriormente. Conseguiu entender? Vamos em frente. Vem comigo que agora nós vamos falar sobre o armazenamento de dados.Bom, gente, uma view é considerada uma tabela virtual, pois ela pode ser acessada em consultas como se fosse uma tabela, só que ela geralmente não armazena dado nenhum. Na verdade, a view só aguarda as consultas que serviram de base para sua criação. Assim, na hora que um usuário ou programa de aplicação os dados do SGBD irá executar a consulta que foi armazenada e buscar os dados diretamente nas tabelas originais, conforme definido pela consulta, isso garante que os dados estarão sempre atualizados de acordo com as tabelas de origem.Resumindo, as views são consideradas tabelas virtuais ou consultas armazenadas, pois elas não armazenam dados fisicamente no banco de dados. Para fins de consultas posteriores ao banco de dados, contudo, as views são praticamente indistinguíveis de tabelas reais, ou seja, pode-se realizar comandos SQL fazendo referência às views como se elas fossem tabelas. Há uma observação importante: como uma view pode ser utilizada e consultada como se fosse uma tabela física temos que uma view também pode ser derivada a partir de outras views. Uma exceção a esse princípio que diz que as views não armazenam dados são as views materializadas. Essas estruturas servem para melhorar a performance de acesso àquelas views que são muito frequentemente utilizadas. Ao materializar uma view o que o SGBD faz é já guardar no banco de dados o resultado trazido pela view. Assim, turma, se economiza tempo ao se realizar uma consulta sobre a view, já que o SGBD já processou a consulta que está armazenada de forma prévia. O problema nesse caso é que o resultado da consulta precisa ser atualizado toda vez que alguma das tabelas que a view consulta é alterada. Tá bom? Vamos ouvir um exemplo: se materializarmos a nossa view do exemplo que eu te dei toda vez que houver alguma modificação na tabela servidores, os resultados da view servidores sem endereço precisará ser atualizado também. Aí nesse cenário há um ganho de performance ao se consultar os dados da view, mas há uma perda de performance na atualização de dados na tabela, já que agora não vai bastar atualizar os dados da tabela, mas também os da view materializada que está associada a ela. Deu pra pegar aí? Beleza. Fico por aqui, tá bom? Obrigado pela companhia! Até daqui a pouquinho tá chegando aí o próximo áudio. Tchau, tchau.

12 - Views

Tecnologia da Informação EmÁudio: As Doze Regras de CODD - Parte 1E aí, galera? Tudo bem? Nesse em áudio nós vamos começar a conversar sobre as doze regras de Codd. Preparado? Aperta o play aí. Vamos lá.IF Codd que podemos identificar como o criador do modelo relacional, definiu um conjunto de regras que determina as condições necessárias para que um SGBD seja considerado relacional. Foi uma tentativa de Codd para que os diversos desenvolvedores de sistemas de banco de dados não se desviassem muito do que foi inicialmente proposto por ele como sendo um banco de dados relacional. Na prática, turma, nenhuma SGB aplica todas essas regras de forma rigorosa. No entanto, as bancas muitas vezes as cobram, então é importante que aprendamos bem esse assunto.A ideia aqui, turma, não é saber listar de cabeça as regras. O importante é que você as entenda e saiba identificá-las nas questões de prova, assim como conseguir identificar eventuais erros ocasionados por trocas de palavras por parte da banca. São doze as regras que Codd definiu para caracterizar um sistema completamente relacional. Todas elas se baseiam em uma regra fundamental que Codd chamou de regra zero. Vamos lá, o que é isso aí?Regra zero: para qualquer sistema que seja propagandeado ou nomeado como um SGBD relacional, esse sistema deverá gerenciar bancos de dados exclusivamente através de suas capacidades relacionais. Então, pessoal, essa regra vai servir de base para a elaboração de todas as outras. Só que ela é bem genérica, então não dá para entender bem o que Codd quer dizer com essas capacidades relacionais. Nas doze regras, poderemos ter uma compreensão melhor do que isso quer dizer. Vamos a elas então.Regra número um: a regra da informação. Todas as informações em um banco de dados relacional são apresentadas logicamente de uma só maneira, como valores em tabelas. O que quer dizer isso aí, pessoal? Tudo, mas tudo mesmo que for armazenado em um SGBD relacional vai ficar guardado de uma só maneira, como dados em tabelas. Isso implica dizer que até mesmo os metadados do catálogo ficam em tabelas. O Catálogo normalmente é implementado na forma de um banco de dados, tendo suas informações organizadas em linhas e colunas de tabelas, da mesma maneira que fazemos com os dados propriamente ditos. Essas tabelas do catálogo irão conter as informações a respeito das estruturas e restrições do restante do banco de dados. Por exemplo, pode existir no SGBD uma tabela do sistema chamada "colunas", que armazena metadados a respeito das colunas das tabelas que fazem parte do banco de dados. Tá bom?Regra número dois: a regra do acesso garantido. Todo dado armazenado em um banco de dados relacional pode ser acessado através da utilização de uma combinação de nome de tabela, valor da chave primária e nome da coluna. Essa regra é simples de se entender. Para começar, nós já sabemos que em um SGBD relacional todos os dados estão armazenados em tabelas. Para localizar um dado específico em uma célula de uma tabela, nós precisamos somente de três informações: qual é a tabela, qual é a linha e qual é a coluna. Podemos encontrar essas informações da seguinte maneira: um, qual é a tabela? Isso nós podemos identificar através do próprio nome da tabela. Dois, qual é a linha? Podemos identificar também através do valor da chave primária, pois ela identifica unicamente cada linha da tabela. E número três: qual é a coluna? Podemos identificar através do nome da coluna. Assim, tendo essas três informações, conseguimos encontrar qualquer dado dentro do banco de dados relacional. Vamos lá!Regra número três: tratamento sistemático dos valores nulos. Os valores nulos, que são diferentes da cadeia de caracteres vazia, do valor zero ou de qualquer outro número, são suportados pelo SGBD relacional para representar informação ausente ou não aplicável e tratados de uma maneira sistemática, independentemente do tipo de dados. Então, a regra parece um pouco complicada, mas é tranquila, pois ela diz o que já sabemos a respeito dos valores nulos. Esses valores não pertencem a nenhum tipo de dados específico, então são diferentes de simplesmente se utilizar uma cadeia de caracteres vazia ou o valor numérico zero, por exemplo. Além disso, pessoal, perceba que os sistemas devem tratar os nulos de maneira sistemática, ou seja, um mesmo valor nulo deve ser utilizado para toda e qualquer coluna que precise. A ideia aqui é não permitir, turma, que cada coluna diferente tenha uma maneira diferente de se representar a ausência de informação. Por exemplo, dizer que o campo CPF deve representar a ausência de informação com o valor dos onze dígitos do CPF, por exemplo: 99999999999, enquanto o nome representaria a ausência com o valor "Xxxx". Todas devem usar o mesmo valor nulo. Ok? Tá conseguindo me acompanhar? Vamos em frente então.Regra número quatro: catálogo online dinâmico baseado no modelo relacional. A descrição do banco de dados está representada no nível lógico da mesma maneira que os dados comuns, para que os usuários autorizados possam aplicar a eles a mesma linguagem relacional que utilizam para os dados normais. Pessoal, essa regra diz respeito ao que conversamos na regra número um. O catálogo está armazenado da mesma maneira que dados comuns, como valores em tabelas. Isso implica dizer que se o catálogo está armazenado como um banco de dados normal, nós podemos utilizar a mesma linguagem de programação que utilizamos para consultar os dados comuns para consultar os dados do catálogo.Regra número cinco: sub-linguagem ampla e compreensiva de dados. O banco de dados relacional pode oferecer suporte a múltiplas linguagens e meios de acesso aos dados. Contudo, deve existir pelo menos uma linguagem declarativa bem definida, com suporte às seguintes operações: preste atenção, um, definição de dados; dois, definição de views; três, manipulação de dados; quatro, restrições de integridade; cinco, autorização; seis, controle de transações. O que essa regra quer dizer, jovem? Gente, ela está basicamente dizendo que um SGBD pode oferecer inúmeras funcionalidades para se trabalhar com os dados. Por exemplo, permitir inserir registros nas tabelas através de uma interface gráfica em que o usuário digite o valor para cada coluna. Só que Codd determinou que o SGBD deve ter pelo menos uma linguagem de programação que englobe todas essas funcionalidades que citei aí, por isso ela será chamada de ampla ou compreensiva. Com a linguagem SQL ficou fácil entender essa regra. Essa linguagem, cujo nome é a sigla para Structured Query Language, atende a todos os requisitos descritos e é a linguagem padrão utilizada em todos os SGBDS relacionais. Até por esse motivo, os bancos de dados relacionais são muitas vezes chamados de bancos de dados SQL. Tranquilo até aqui, né? Bom, gente, vou finalizar esse áudio para não ficar muito cansativo. Tá bom? Já, já eu tô de volta para dar continuidade às doze regras de Codd. Até o próximo áudio.

13 - As 12 Regras de CODD - Parte 1

Tecnologia da Informação EmÁudio: As Doze Regras de CODD - Parte 2E aí turma querida. Tudo bem? Vamos continuar nosso papo sobre as doze regras de CODD? Som na caixa. Paramos na regra número cinco, né, na aula passada.Vamos seguir nossos estudos, então. Regra número seis: atualização de views. Toda views, que é teoricamente atualizável, deve ser também atualizável na prática por meio do sistema.Então, gente, essa regra é bem peculiar e não tem muito uso prático. Então, acredito que se ela for cobrada, será cobrada de maneira literal. Ela está relacionada à utilização de views para realizar a atualização de dados nas tabelas que a view consulta. A ideia aqui é que, por exemplo, se uma views V consulta dados de duas tabelas T um e T dois, nós podemos rodar um comando SQL sobre V para inserir, modificar ou remover dados de T um e T dois. É meio esquisito e complicado fazer isso, já que as views podem envolver várias manipulações sobre os dados que tornem esse procedimento impossível. A regra basicamente diz que se tem um jeito teórico de se fazer isso, o SGBD tem que implementar e permitir que se faça na prática.Regra número sete: Inserção, atualização e exclusão de alto nível. A capacidade de gerenciar uma relação base ou uma relação derivada com um só operando se aplica não somente à extração de dados, mas também à inserção, atualização e remoção dos dados.Eu sei, eu sei, o texto é um pouquinho estranho, mas a regra nem tanto. Ela diz que você deve ser capaz de fazer referência a tabelas e conjuntos de registros dessa tabela no banco de dados somente através de um comando, sem a necessidade de fazer operações registro a registro. Essa operação, pessoal, pode ser tanto uma extração de dados quanto uma inserção de um novo registro, uma atualização ou remoção. Vamos a um exemplo? Imagine que o órgão concedeu um aumento de dez no salário de todos os servidores. Para refletir essa mudança no banco de dados, nós poderíamos simplesmente enviar um comando em linguagem SQL que, traduzindo em português, significaria mais ou menos o seguinte: atualize o valor do atributo salário de todos os registros da tabela servidor para um valor dez por cento maior que o atual. Perceba que não precisamos ir à tabela funcionário e manualmente listar todos os servidores e listar um por um. Nós simplesmente pedimos ao SGBD que realize a atualização para todos os servidores, ou em outros casos, para um subconjunto deles, né? O SGBD se encarrega de encontrar a melhor maneira de fazer isso.Agora uma dica, jovem: as regras de oito a onze tratam de diversos tipos de independência. O objetivo global é o mesmo, tá? Isolar diferentes camadas do sistema de banco de dados umas das outras para que modificações em um nível não influenciem nos demais. Preste atenção, vamos lá então.Regra número oito: Independência física de dados, programas de aplicação e atividades terminais não são logicamente afetados quando mudanças são feitas na representação de armazenamento ou nos métodos de acesso do banco de dados.Turma, já falamos sobre isso quando estudamos as três etapas dos projetos de bancos de dados: projetos conceitual, lógico e físico, lembra? A Independência Física diz que você pode alterar detalhes de implementação física dos dados, como a maneira que esses dados estão armazenados no disco ou os métodos de acesso internos do SGBD, incluindo a definição de índices, sem que o modelo lógico ou o conceitual e, por consequência, os programas de aplicação sejam afetados. Regra número nove: Independência lógica de dados, programas de aplicação e atividades terminais não são logicamente afetadas quando mudanças que preservem as informações são realizadas sobre as tabelas. Essa regra é similar à anterior, mas diz que as alterações no modelo lógico, desde que preservem as informações presentes nas tabelas, não devem afetar as aplicações ou recursos externos. Por exemplo, se você usa views para permitir o acesso aos dados por parte dos programas de aplicação, você pode modificar as estruturas das tabelas que a via utiliza como base para consultar os dados, sem que isso altere a visão que os programas de aplicação têm sobre os dados, já que eles estão enxergando apenas o resultado da view.Regra dez: Independência de integridade. As restrições de integridade específicas de um banco de dados relacional devem ser definíveis na linguagem relacional e armazenáveis no catálogo não nos programas de aplicação.Gente, essa regra é interessante. Preste atenção. Ela diz que as restrições de integridade devem ser gerenciadas pelo SGBD e não pela aplicação. Por exemplo, não é necessário que o programa de aplicação que utilize o banco de dados se preocupe em gerenciar se um atributo que faça parte de uma chave primária de uma tabela é realmente único ou não. De acordo com essa regra, o próprio SGBD que deve fazer essa verificação e levantar um erro toda vez que você tentar duplicá-las ou deixar um valor nulo em alguma delas. Essa regra também diz respeito à possibilidade de se definir outros tipos de restrição referentes às regras do negócio diretamente no catálogo, no lugar de deixar com os programas de aplicação. Tranquilo até aqui, né? Me acompanhe até o próximo áudio para finalizarmos nosso papo sobre as doze regras de CODD. Vamos lá! Abraço.

14 - As 12 Regras de CODD - Parte 2

Tecnologia Da Informação EmÁudio: As Doze Regras de CODD - Parte 3E aí, pessoal.  Sem enrolação, bora finalizar essas doze regras de CODD. Aperte o play. Vem comigo.Regra número onze: Independência de distribuição. Um SGBD relacional tem independência de distribuição. Então, turma, os bancos de dados distribuídos são aqueles cujos dados estão armazenados em múltiplos locais, sejam múltiplas máquinas no mesmo local físico, ou diferentes computadores espalhados por cidades, estados ou até mesmo países diferentes. A regra diz basicamente que a localização física dos dados não deve ser da preocupação do usuário, ou seja, o usuário não enxerga nem é afetado pela localização dos dados. Ele vai simplesmente trabalhar com os dados e executar comandos SQL da mesma maneira que faria se estivessem todos armazenados no mesmo servidor. O termo servidor aqui está sendo utilizado no sentido de máquina, com alto poder de computação e que geralmente hospedam o banco de dados.E, por fim, turma, a regra número doze: Regra da não subversão ou não transposição. Se o sistema relacional possui uma linguagem de baixo nível, uma linguagem que permite manipular registros individuais, esse baixo nível não pode ser utilizado para subverter ou contornar as restrições de integridade que foram criadas pela linguagem relacional de alto nível, aquela que permite manipular conjuntos de registros de uma vez. Então, para entender melhor essa regra, relembre a regra número sete. Ela diz que o sistema deve dar suporte a uma linguagem de alto nível, ou seja, que permite trabalhar com vários registros de uma vez através de um só operando. A ideia desta regra número doze é dizer que mesmo que o sistema tenha uma outra linguagem, esta de baixo nível, que só permite manipular um registro de cada vez, ela não pode ser usada para violar as restrições de integridade que foram definidas com uma linguagem de alto nível.Pode parecer uma coisa muito específica e é mesmo, mas lembre-se que essas regras foram definidas na década de oitenta, época em que muitos SGBDs relacionais estavam surgindo. Alguns desses sistemas novos eram somente adaptações de outros sistemas que anteriormente possuíam essas linguagens de baixo nível, e por isso apresentavam vulnerabilidades como a que é descrita nesta regra, o que poderia comprometer a integridade dos dados.Essas são as doze regras, turma. A ideia central é que você memorize os enunciados e tente entendê-las na medida do possível. Tá bom? Lembre-se que é mais fácil de memorizar e reconhecer eventuais erros se você pegou o espírito de cada uma delas. No em áudio que vem, nós falaremos da Álgebra Relacional. Te espero lá, hein? Tchau, tchau.

15 - As 12 Regras de CODD - Parte 3

Tecnologia da Informação EmÁudio: Álgebra RelacionalOlha nós aí. Preparados para aprender sobre a álgebra relacional? Muito bem, turma. Cola em mim e aumenta esse som aí.A Álgebra Relacional é a linguagem formal do modelo relacional. Ela é um conjunto de operadores que permite extrair informações de um banco de dados relacional de diversas maneiras. A ideia aqui é listar as possibilidades com que podemos manipular e combinar os dados das relações para obter várias perspectivas diferentes sobre os dados.É como se fosse, pessoal, operações matemáticas. Tá? Só que sobre os conjuntos de dados que são as relações. Os operadores relacionais envolvem uma ou mais relações e a partir delas produzem uma nova relação que é o resultado da operação. Um detalhe é que a álgebra relacional não é utilizada diretamente nos SGBDs, mas muitos de seus conceitos servem de base para operações da linguagem SQL, que é a linguagem prática utilizada nos SGBDs relacionais. Assim como uma relação no modelo relacional teórico dá origem a uma tabela na prática, um operador nacional pode dar origem a um comando SQL. Para nossa aula, eu trouxe alguns operadores importantes para você e os dividi em dois grupos, tá.Os primeiros são aqueles baseados nas operações tradicionais de conjuntos matemáticos. Lembra que uma relação nada mais é do que um conjunto de duplas? Então os operadores que são aplicáveis a conjuntos matemáticos são, por consequência, aplicáveis a relações. Já os operadores do segundo grupo são orientados especificamente a relações.Primeiro grupo: Operadores baseados em conjuntos. Vamos lá. Para as primeiras três operações, vamos utilizar duas tabelas de exemplo. Tabela A contém dados de servidores e a tabela B de instrutores dos cursos do órgão. Esses cursos ministrados pelo órgão podem ter como instrutores os próprios servidores da casa também presentes na tabela de servidores ou professores externos. A primeira situação é a de união das tabelas A e B. Aqui retorna a uma relação que é a união de todas as duplas da relação A com todas as duplas da relação B, sem valores duplicados.Ou seja, galera, vamos juntar todos os registros das duas tabelas envolvidas e manter somente aqueles que são únicos, descartando as repetições. Para que essa operação possa ser realizada, as duas relações envolvidas devem ter os mesmos tipos de atributos e o mesmo grau.Ou seja, não dá para unir uma relação com três colunas com uma de duas colunas ou mesmo unir uma coluna que só contenha números com uma que contenha cadeia de caracteres. Certo? Isso não faria sentido mesmo, já que o propósito da união é realmente unir conjuntos semelhantes.A segunda situação é a de interseção entre as tabelas A e B. Neste caso, pessoal, retorna as duplas em comum entre as relações A e B. Ou seja, aqui são retornadas somente aquelas duplas que existem, tanto em A quanto em B. Assim como ocorre na união, para que se possa realizar a operação de interseção, ambas as relações também devem ter atributos compatíveis, mesmos tipos e mesmo grau da relação.Agora é a terceira situação. É a diferença A menos B que traz todas as duplas da relação A menos as que também estão presentes na relação B. Aqui, pessoal, é importante notar que, ao contrário do que acontece com as anteriores, a ordem das duplas vai afetar o resultado dessa operação. Tá? Já que A menos B é diferente de B menos A. Tranquilo até aqui?Então a quarta situação é a de produto cartesiano, A vezes B, que combina as linhas e colunas das relações A e B, resultando em uma relação que possui todos os atributos presentes nas duas originais. Deu para entender? Agora vamos para o segundo grupo. Operadores específicos para banco de dados relacionais. No segundo grupo temos a primeira situação a de Seleção.Jovem, a seleção retorna determinadas duplas de uma relação limitadas por condições especificadas, o que se conhece geralmente como uma filtragem dos registros.A segunda situação é a de projeção. Enquanto a seleção filtra duplas da relação, a projeção filtra atributos, ou seja, a projeção extrai somente alguns atributos de uma dupla ou um conjunto de duplas, omitindo os demais.A terceira situação, pessoal, seria de junção. Então a junção serve para combinar duas relações com base nos valores de um atributo que elas tenham em comum. Ela resulta em uma relação que contém os atributos de ambas as relações com suas duplas ligadas umas às outras. Pense exatamente na ligação de duas tabelas através de chave estrangeira. O objetivo aqui é combinar as duas tabelas através dessa ligação. As duplas que possuem o atributo chave do relacionamento com valores em comum são combinadas, gerando uma relação maior.Esta operação é importantíssima, já que permite que se processe os relacionamentos em um banco de dados relacional. Há outros operadores relacionais, incluindo diferentes tipos de junção, operadores de renomear, que renomeia um atributo ou relação, e a divisão relacional, que funciona a primeira relação baseada na segunda. Mas acredito que pouco produtivo sair listando e explicando todos eles. Ok?A intenção aqui não é esgotar o assunto de banco de dados relacionais, já que poderíamos escrever dezenas de livros a respeito. A ideia, como sempre no em áudio, é focar no nível de exigência adequado para a sua prova. Então vamos ficar por aqui com a álgebra relacional. Tá bom? No em áudio que vem vamos estudar a normalização. Até daqui a pouquinho! Tchau, tchau.

16 - Álgebra Relacional

Tecnologia da Informação EmÁudio: NormalizaçãoE aí, meu jovem! Beleza? Bora ser aprovado? Hora de falarmos da normalização. Aquele sorriso no rosto, foco e vem comigo.Gente, a normalização foi proposta por Codd em 1970, como sendo parte do modelo relacional. Ela consiste em algumas técnicas utilizadas para eliminar valores não atômicos e reduzir a redundância de dados. Essas redundâncias, como já discutimos, poderiam causar problemas como a necessidade de manutenção dos mesmos dados em diversas tabelas diferentes, o desperdício de espaço em discos e perda de performance na escrita no banco de dados. Dessa forma, os objetivos da normalização podem ser sistematizados desta maneira: reduzir a redundância de dados, organizando as tabelas de modo a facilitar a manutenção, a atualização de dados e a evolução do modelo, e garantindo assim a integridade dos dados, gente.A normalização é frequentemente utilizada nos bancos de dados relacionais, pois eles costumam ser usados por aplicações ditas transacionais, que são aquelas que estão sempre atualizando dados no banco. Com uma quantidade menor de redundâncias no banco de dados, essas atualizações podem se processar de maneira mais eficiente.A normalização é um processo que consiste em aplicar várias regras sequenciais em etapas. Cada uma dessas regras é conhecida como uma forma normal e se destina a eliminar algum tipo de redundância de dados. Essas formas normais, pessoal, são cumulativas, ou seja, para um banco de dados estar na terceira forma normal, chamada de 3FN, ou em inglês, ele também tem que estar necessariamente na primeira forma normal, 1FN, e na segunda, 2FN, e assim sucessivamente.Codd inicialmente propôs três formas normais que são difundidas até hoje nos ambientes de banco de dados e geralmente se considera suficiente para eliminar a maior parte das redundâncias do modelo. Além disso, turma, depois da terceira, as regras vão ficando um tanto complicadas. Sabe? Então, boa parte dos desenvolvedores dos bancos de dados não as adotam. Assim, em geral, um banco de dados pode ser dito normalizado se atende a 3FN. Vamos conferir essas três primeiras formas normais. Vamos lá: Uma tabela está na 1FN somente se todos os seus atributos são atômicos. Gente, essa primeira regra é bem tranquila, tá? A ideia é que os atributos compostos devem ser desmembrados em suas partes atômicas. Os atributos multivalorados devem ser representados com o auxílio de uma tabela auxiliar, como já vimos durante a aula.Número dois, vamos comigo. Uma tabela está na 2FN somente se está na 1FN e seus atributos não chave dependem da chave primária inteira. Ou seja, eles não podem apresentar dependências parciais. Turma, para entender melhor essa e a próxima forma normal, é importante que você entenda o conceito de dependência funcional. O que é isso aí? Gente, uma dependência funcional entre dois atributos ou conjuntos de atributos X e Y ocorre quando o valor de X é capaz de determinar o valor de Y.Isso quer dizer que toda vez que o valor de X for X um, por exemplo, o valor de Y será o mesmo. Para o mesmo valor do atributo X na tabela, não haverá dois valores diferentes do atributo Y. Agora, em relação às chaves primárias, a ideia da 2FN é que não pode haver dependências parciais no caso de haver uma chave primária composta. Ou seja, pessoal, um atributo não chave não pode ter dependência funcional em relação a só uma parte dos atributos que compõem a chave. Isso vai ficar mais fácil de entender com um exemplo. Vamos lá. Imagino uma tabela produtos que registre informações a respeito de produtos comercializados por uma empresa. Ok? Imaginou? Vamos lá. Ela vai ser dividida em: fabricante, produto, preço unitário e país fabricante.A chave primária dessa tabela é composta pelos campos sublinhados: fabricante e produto. Os atributos preço unitário e país fabricante são atributos não chaves. Então, para atender a 2FN, ambos deveriam ser determinados somente pela chave primária inteira. Nunca somente por fabricante ou somente por produto. Agora perceba que é uma dependência parcial em relação a chave primária. O atributo país fabricante é uma informação que está relacionada somente ao fabricante do produto independentemente de qual produto específico se trata. Ok?Todo o produto da empresa A, por exemplo, terá o valor de país fabricante como China, por exemplo. Tá conseguindo imaginar aí? Ok. Dessa maneira, é possível determinar o atributo país fabricante somente com a informação do fabricante que é somente parte da chave primária da tabela produtos.Então do ponto de vista do atributo país fabricante, o valor atributo do produto, a outra parte da chave primária, né, é absolutamente irrelevante. Segundo a 2FN isso não pode ocorrer pois é uma dependência parcial em relação a chave primária. Percebeu? Para resolver essa situação vai ser necessário desmembrar uma nova tabela a partir de produtos somente para guardar os dados que dizem respeito aos fabricantes dos produtos.Então, ficaremos com uma tabela com fabricante, produto e preço unitário, tá, turma. Se desmembrarmos apenas com informações do fabricante teremos: fabricante e país fabricante. Deu para entender? Além dessas duas formas normais, pessoal, que acabamos de conversar temos mais uma. Lembra que são três, né? Ouça bem. Uma tabela está na 3FN somente se está na 2FN e nenhum dos seus atributos não chave apresente dependência transitiva em relação a chave. Ou seja, nenhum atributo não chave apresente dependência funcional em relação a outra atributo não chave. Galera, essa forma normal tem um exemplo muito clássico que vai te ajudar a resolver a maior parte das questões de prova a respeito.Então vamos direto a ele. Imagine uma tabela de vendas em uma empresa comercial, tá legal? Ela vai possuir vendedor, produto, data, quantidade, valor unitário e o valor total. O valor do atributo valor total pode ser determinado através de um cálculo de multiplicação entre os campos quantidade e valor unitário. Assim, toda vez que quantidade for três e o valor unitário for quinze, por exemplo, o valor total será quarenta e cinco, não há outra possibilidade.Isso quer dizer, galera, que o atributo valor total apresenta dependência funcional em relação aos atributos quantidade e valor unitário. Só que o problema é que quantidade e valor unitário são atributos não chave da relação, pois eles não são chave primária nem chave candidata. Para 3FN, isso não pode. Essa dependência do atributo valor total em relação à chave primária é dita transitiva, pois é uma forma de dependência indireta em relação à chave. Isso se dá, turma, porque todos os atributos de uma tabela na 2FN dependem da chave primária.Assim como quantidade e valor unitário dependem da chave primária e o valor total, por sua vez, depende de quantidade e valor unitário, temos uma relação de dependência indireta entre valor total e a chave primária. Para resolver essa situação, como o valor total pode ser obtido através de um simples cálculo entre os demais atributos, poderíamos simplesmente omiti-lo da tabela e calcular seu valor quando necessário. Se fosse um atributo mais importante que não pudesse ser obtido dessa maneira, poderíamos desmembrar essa tabela, colocando esse atributo dependente em outra tabela, a exemplo do que fizemos na 2FN.Resumindo, jovem, normalização é o processo de aplicação de regras para a eliminação de redundâncias do modelo de dados: 1FN, todos os valores dos atributos devem ser atômicos, elimina atributos compostos e multivalorados; 2FN, elimina dependências parciais em relação à chave primária; e 3FN, elimina dependências transitivas em relação à chave. Assunto entendido? Espero que sim. No em áudio que vem faremos o nosso super resumão e revisaremos os pontos mais importantes desse módulo. Até lá.

17 - Normalização

Tecnologia da Informação EmÁudio: Resumão sobre Modelo Relacional de Dados - Parte 1Bom dia! Boa tarde! Boa noite! Independentemente do horário que você esteja me escutando é sempre um prazer ter você aqui comigo, tá bom. Neste em áudio, nós revisaremos os pontos mais importantes desse módulo. É o resumão da aprovação. Vamos lá pra esse super resumão! Aumenta o som e vem comigo.Vou começar então o nosso super resumão falando rapidinho do modelo relacional, tá bom. Podemos dizer que o modelo relacional apresenta três elementos marcantes: Relações, restrições de integridade e operadores relacionais. Relações são estruturas similares a tabelas que são as estruturas que armazenam os dados. Restrições de integridade são o conjunto de regras que ditam o que essas tabelas podem conter e como elas se relacionam. E operadores relacionais são operações matemáticas que servem de base para a manipulação e extração dos dados.Vamos revisar rapidinho cada um desses elementos. Vem comigo. Jovem, os bancos de dados relacionais são exemplos de coleções de dados estruturados. Isso acontece porque os dados estão armazenados em estruturas fixas, que seguem um esquema pré-definido. No caso dos bancos de dados relacionais, essa estrutura é a relação; quando colocamos a relação no formato de tabela, cada linha é chamada de dupla e cada coluna corresponde a um atributo. As duplas irão caracterizar as ocorrências do que está sendo representado na relação, enquanto os atributos irão representar as características relativas a essa coisa, chamamos assim, que está sendo representada. Formalmente falando uma relação não é exatamente uma tabela, mas pode ser definida como um conjunto não ordenado de duplas.Grave essa definição tá legal, porque ela é cobrada em prova. Repita comigo então aí para marcar: uma relação é um conjunto não ordenado de duplas.Além disso, meu jovem, tenha sempre em mente que uma relação é um conjunto não ordenado de duplas, e uma dupla é um conjunto dos valores dos atributos. Um detalhe em relação aos atributos, que são definidas regras que ditam os valores que eles podem assumir. Uma regra que precisa ser definida para todos os atributos em um SGBD relacional é o tipo de dados; o tipo é uma restrição que indica qual é a natureza do dado. Por exemplo, se ele é um número inteiro, número decimal, cadeia de caracteres, data, dentre outras possibilidades, né? Uma dica pra você: Atributos textuais geralmente são do tipo cadeia de caracteres geralmente chamado de vachar ou char nos SGBDs.Tranquilo até aqui, né? Vamos para as chaves e relacionamentos.Como já conversamos, os SGBDs não somente gerenciam o armazenamento dos dados, mas também são responsáveis por gerenciar e definir uma série de regras para os dados. Por exemplo, através do SGBD, nós podemos definir como as tabelas ficam estruturadas e o domínio para cada atributo. Outro tipo de restrição ou regra que pode ser definido através dos SGBDs são as chaves. As chaves são as estruturas que permitem identificar e relacionar as tabelas. Uma outra questão muito importante é que os atributos que compõem uma chave primária não podem assumir o valor null. Isso acontece porque o nulo representa uma ausência de informação. Então, tecnicamente, não é possível realizar várias comparações com ele em um SGBD relacional. A chave estrangeira, jovem, lembra dela? Pessoal, o objetivo desse tipo de chave é basicamente possibilitar que se criem ligações lógicas entre as tabelas, permitindo a representação dos relacionamentos. As chaves estrangeiras geralmente ficam representadas nos modelos lógicos através da sigla FK, que é chave estrangeira em inglês. Ou seja, Foreign Key. Conseguiu me acompanhar até aqui? Calma que ainda não acabou. No em áudio que vem nós revisaremos mais alguns pontos importantes.Até lá. Até o próximo áudio.

18 - Resumão EmÁudio sobre Modelo Relacional de Dados - Parte 1

Tecnologia da Informação EmÁudio: Resumão sobre Modelo Relacional de Dados - Parte 2Fala, jovem. Sem enrolação. Vamos dar continuidade ao nosso super resumão. Som na caixa então.Hora de falar da integridade. Gente, a integridade de um sistema pode dizer respeito ao aspecto físico do mundo real que diz respeito ao armazenamento dos dados em um meio físico, como em um HD ou fitas de backup, mas a integridade, gente, que foi objeto do nosso estudo foi uma integridade lógica, ou seja, aquela que tem a ver com os aspectos do software do banco de dados, como as regras que foram definidas ao se projetar o banco de dados.Como já mencionamos em várias partes da nossa aula, um banco de dados relacional possui um conjunto de regras como os dados devem estar organizados e relacionados.Para fins de prova, penso que memorizar as restrições de integridade que vou listar aqui é importante e é o suficiente. A primeira restrição de integridade que vamos conversar é a integridade de entidade. O que que é isso aí? Esse tipo de restrição está relacionado às regras impostas pelas chaves primárias. A integridade de entidade define somente que cada chave primária deve ser única e não nula também é conhecida como integridade primária ou de chave primária.Segundo a restrição de integridade, vamos lá. Integridade referencial. Turma, a integridade referencial está relacionada ao conceito de chave estrangeira. A regra simplesmente determina que uma chave estrangeira só pode estar em dois estados: fazendo referência a um registro válido da tabela referenciada, ou assumindo o valor null caso em que o registro em questão não participa do relacionamento. Lembrando que esse último caso só é possível no caso de participação parcial da entidade no relacionamento. A ideia aqui, gente é basicamente que uma chave estrangeira deve estar referenciando corretamente um registro da tabela referenciada ou não referenciando ninguém.Terceira e última restrição de integridade, a integridade de domínio. Pessoal, o domínio é o conjunto dos valores possíveis para um determinado atributo. Dessa forma, a integridade de domínio determina que os valores de todas as colunas em todos os registros de um banco de dados fazem parte de seus respectivos domínios. Dentro da integridade de domínio, temos uma subcategoria chamada integridade de vazio. Essa restrição determina se o atributo pode ou não assumir valores nulos. Tranquilidade total, né?Vamos para as views, vamos lá. A view é uma visão diferente sobre os dados que estão armazenados em tabelas do banco de dados. Nós sempre definimos uma view a partir de uma consulta SQL, tá bom? E para finalizar nosso super resumão, preciso falar rapidinho da normalização, né? Gente, a normalização foi proposta por CODD em 1970 como sendo parte do modelo relacional. Ela consiste em algumas técnicas utilizadas para eliminar valores não atômicos e reduzir a redundância de dados. Dessa forma, os objetivos da normalização podem ser sistematizados assim reduzir a redundância de dados organizando as tabelas de modo a facilitar a manutenção, a atualização de dados e a evolução do modelo e garantindo assim a integridade dos dados. Assunto entendido e revisado?Posso ir embora? Beleza, mas eu volto para o próximo módulo, claro. Se preparem, hein. Beleza gente. Obrigado pela sua companhia, tá jovem.Bons estudos e boa sorte, conte comigo, abraço e até o próximo módulo!

19 - Resumão EmÁudio Modelo Relacional de Dados - Parte 2

Tecnologia da InformaçãoMÓDULO 02Modelo Relacional de DadosArthur Mendonça

Arthur Mendonça