Usando Aliases e Literais de Strings - SQL na Prática

O que são Aliases

As aliases podem ser atribuídas para colunas na lista de seleção e para fontes de dados na cláusula FROM; Declarações de SELECT podem ser feitas facilmente para serem lidas usando ALIASES (apelidos).

Aliases, tanto para colunas e tabelas, dentro de uma instrução SELECT são feitas para tornar a digitação e a leitura da declaração mais simples;

As Aliases não fazem somente a declaração mais fácil de ler, mas também podem fazer mais fáceis de ler e interpretar o conjunto de resultados;

Na prática:
- A cláusula opcional AS pode ser adicionada para que a declaração fique mais legível;
Ambas as declarações abaixo são equivalentes;

SELECT e.ContactID AS 'Employee Identification Number'

FROM HumanResources.Employee AS e

SELECT e.ContactID 'Employee Identification Number'

FROM HumanResources.Employee AS e

Literais de string:

- São valores constantes;
- Pode ser inserida dentro de uma coluna derivada para formatar um dado;
- Pode ser usada como valores alternativos em funções, como na função ISNULL();

-- Se MiddleName for null, ele retorna o '' (sem espaço)
-- Substring pega a desde a posição 1 (1º parâmetro)
-- de MiddleName, mais 1 caractere (2º parâmetro)

SELECT (LastName + ',' + FirstName + ''
 + ISNULL(SUBSTRING(MiddleName,1,1),'')) as Name
FROM Person.Contact
ORDER BY LastName,FirstName,MiddleName;

SELECT (LastName + ',' + SUBSTRING(FirstName,1,2)) as Name
FROM Person.Contact
ORDER BY LastName,FirstName,MiddleName;

Literais de strings são Strings estáticas que são inseridas dentro de colunas derivadas, como uma vírgula entre partes de um nome concatenado. Eles também podem ser usados como valores alternativos em vez do valor da coluna numa função como NULLIF() e COALESCE().

- Aliases de Colunas e tabelas não são literais de Strings;
- Literais de strings podem ser usadas por funções como retorno de valores alternativos;

Mapeando MER para o Modelo Relacional | Atributos Multivalorados, Agregação e Relacionamento 1 para 1

• Atributos Multivalorados: novas tabelas devem ser criadas para armazená-los juntamente com a chave primária da entidade que os possui. Exemplo:

Livros (No_tombo, título, ano, editora)

Autores (No_tombo, autor)

• Agregação: como a agregação é a representação de um conjunto de relacionamentos como se fosse um conjunto de entidades, o mapeamento para tabelas é semelhante ao mapeamento aplicado em entidades e relacionamentos normais.
• Relacionamentos de 1 para 1: para decidir como será feita a transposição de chaves, deve-se observar a participação total com relação ao relacionamento.

Exemplo:

Todo país tem uma capital, mas nem toda cidade é capital de um país, portanto a tabela de países é que deve receber a código da cidade que é capital.

Países (código, nome, continente, código_capital)

Cidades ( código, nome, população)

OBS: Relacionamentos Binários de 1 para n podem gerar tabela quando não há totalidade na associação.

Fonte: Apostila professores Cláudio e Carrilho, download em Março/2006

Mapeando MER para o Modelo Relacional | Generalização e Especialização

• Generalização e Especialização: há duas maneiras de definir as tabelas para uma generalização ou especialização:
• Define-se uma tabela para o conjunto de entidades do nível mais alto (com os atributos comuns) e uma tabela para cada entidade do nível mais baixo (com seus atributos próprios + a chave primária da entidade do nível mais alto). Exemplo:

Contas (número, saldo)

Contas_corrente (número, limite)

Contas_poupança (número, data_base)

• Define-se tabelas apenas para os conjuntos de entidades do nível mais baixo (com seus atributos próprios, mais todos os atributos herdados do conjunto de entidades do nível mais alto).
  Essa opção só é permitida se a generalização / especialização for mutuamente exclusiva (uma entidade não pertence a mais do que um dos subconjuntos) e total (todas as entidades do nível mais alto pertencem a um dos subconjuntos do nível de baixo). Exemplo:

Contas_corrente (número, saldo, limite)

Contas_poupança (número, saldo, data_base)

Fonte: Apostila professores Cláudio e Carrilho, download em Março/2006

Mapeando MER para o Modelo Relacional | Relacionamentos

• Conjunto de Relacionamentos: podem ou não gerar tabelas:
• Relacionamentos Múltiplos ou Relacionamentos Binários de N para N: geram tabelas com as chaves primárias das entidades envolvidas mais os atributos próprios do relacionamento. Exemplo:

                 
                Usuários (COD, nome, fone)

                Livros (No_tombo, título, ano, editora)

                Empréstimos (COD, No_tombo, data_ret, data_dev)

• Relacionamentos Binários de 1 para N ou de 1 para 1: não geram tabelas. Para associar as tuplas das tabelas no Modelo Relacional deve-se transpor a chave de um conjunto de entidades para o outro ( a chave da entidade do lado com 1 é transposta para a entidade do lado n). A chave transposta nesse caso não compõe a chave primária da entidade que a recebeu (é uma chave estrangeira).
  Obs: no caso da transposição de chave entre a entidade forte e a entidade fraca que dela depende, a chave transposta compõe a chave primária da entidade fraca). Exemplo:

                 Países (código, nome, continente)

                 Cidades ( código, nome, população, código_país)

Fonte: Apostila professores Cláudio e Carrilho, download em Março/2006

Mapeando MER para o Modelo Relacional | Entidades

Um Diagrama de Entidade relacionamento pode ser representado por um conjunto de tabelas ( esquema do Modelo Relacional)

• Conjunto de Entidades: cada conjunto de entidades do DER gera uma tabela no Modelo Relacional.
• Entidades Fortes: tabela com seus atributos próprios

Contas (Número, saldo)

• Entidades fracas: tabela com chave primária da entidade forte da qual ela depende mais seus atributos próprios

Carros (chassi, marca, modelo, ano, cor, placa)

Reparos (chassi, data, tipo, valor, oficina)

Fonte: Apostila professores Cláudio e Carrilho, download em Março/2006

Modelo Relacional e suas Definições

• Banco de Dados representado por um conjunto de tabelas também chamadas de relações (relacionam um conjunto de valores).
• Cada linha de uma tabela também é chamada de uma tupla. (n-upla).
• Esquema de um BD Relacional: definição do conjunto de tabelas e seus atributos que irão compor a base de dados (estrutura do BD relacional)
• Instância de um BD Relacional: conjunto de dados armazenados no BD em um determinado momento.

Exemplo:

  Esquema:

    usuários ( código inteiro [chave primária],

                   nome caracteres [30],

                   end_rua caracteres [20],

                   end_número inteiro,

                   ....)

    livros ( código inteiro [chave primária],

               título caracteres[20],

               editora caracteres[10],

               ano_pub inteiro)

    empréstimos ( cod_usuário inteiro [chave primária],

               cod_livro inteiro [chave primária],

               data_ret data [chave primária],

               data_dev data )

Instância:

Fonte: Apostila professores Cláudio e Carrilho, download em Março/2006

Integridade Referencial - Banco de Dados

É um mecanismo utilizado para manter a consistência das informações gravadas. Dessa forma, não são permitidas a entrada de valores duplicados nem a existência de uma referência a uma chave inválida em uma entidade.

É importante enfatizar o conceito de integridade referencial. É também necessário que cada valor de chave estrangeira possua uma ocorrência na outra entidade à qual faz referência. Se isso não ocorrer, fica claro que estaremos perdendo uma informação importante para o sistema. Exemplo: se tivermos um valor na entidade CD correspondente à gravadora (chave estrangeira) e não tivermos o mesmo valor (chave primária) na entidade Gravadora, estaremos diante de um problema, pois teríamos um CD sem uma Gravadora válida.

A maior parte dos bancos de dados relacionais estabelece esse tipo de relacionamento e impede que durante uma inclusão, exclusão ou alteração uma chave estrangeira de uma entidade não tenha correspondente na chave primária da outra entidade. Assim, em uma inclusão na entidade com a chave estrangeira, caso seja informado um código que não exista, correspondente na outra entidade, deve ser gerada uma mensagem de erro. Assim, caso queiramos incluir um CD com um código de Gravadora que não exista, correspondente na tabela Gravadora, deve ser enviada uma mensagem de erro e impedida a gravação da informação.

No caso de uma alteração ou exclusão na chave primária da entidade, deve-se verificar se há registros dependentes (chave estrangeira) nas demais tabelas. Se houver, deve-se excluir todos os registros dependentes ou alterá-los, dependendo do caso. Isso poderia ocorrer caso quiséssemos excluir ou alterar uma Gravadora e tivéssemos CDs armazenados com o código da Gravadora. Se fosse permitido, teríamos uma informação inválida, pois ao tentarmos localizar a Gravadora deste CD, isso não seria possível.

Caso o seu banco de dados não disponha desse recurso, você deverá levar isso em consideração e criar mecanismos que evitem o problema. Quanto o banco de dados dispuser desse recurso, este adotará o nome CONSTRAINT.

Em alguns bancos de dados é possível controlar até a propagação de exclusões ou alterações na chave primária: ou se apagam todos os registros dependentes ou se altera o seu código. Assim, caso excluíssemos ou alterássemos uma determinada Gravadora, todos os CDs dessa gravadora seriam automaticamente excluídos ou alterados. Note que isso é bastante perigoso, pois normalmente nenhuma mensagem será dada ao usuário. A regra será a automática modificação das informações no banco de dados.

Especificação - MER

As técnicas de orientação a objetos tiveram várias influencias sobre o projeto de bases de dados. Uma delas é o conceito de subclasse e herança. Muitas vezes queremos registrar características especiais de certos subconjuntos de um CE. Por exemplo, no CE Funcionários temos secretária, técnicos, engenheiros, gerentes etc, e para cada uma dessas categorias queremos guardar alguns atributos específicos, como habilidades das secretárias em digitação, informática, línguas etc. Outros atributos seriam requeridos para engenheiros e assim por diante. Seria ineficiente estender o CE Funcionários com todos esses atributos que só teriam valores para cada grupo específico de funcionários ficando vazios os não correspondentes ao grupo. Para este fim criamos os CE´s denominados Secretárias, Técnicos, Engenheiros etc, e um tipo especial de relacionamentos desses CE´s chamado “é um” e representado por um triângulo.

Esses novos CE´s são também chamados de especializações do CE Funcionários. Como o nome “é-um” indica, o relacionamento significa que uma secretária “é uma” funcionária, isto é, possui todos os atributos do CE funcionário.

O símbolo “+” indica que a especialização é do tipo “ou exclusivo”, ou seja, um funcionário pode ser especializado em apenas um dentre “Secretárias”, “Técnicos” e “Gerentes”.

Agregações - MER

Há casos em que relacionamentos de grau superior a 2 não capturam as regras de negócio desejadas. Por exemplo, no relacionamento triplo MRP visto anteriormente em materiais, requisições e pedidos (ordens de compra), uma requisição está relacionada com um ou mais materiais e com um ou mais pedidos (ou com nenhum deles), o que é artificial.

Requisições precedem a pedidos no tempo e originalmente estão relacionadas apenas com Materiais, já que toda requisição é criada para comprar um ou mais materiais. Elas se originam em diversos setores da empresa e são encaminhadas ao setor de compras. O setor de compras associa um pedido de compra ao par (requisição, material), portanto, ao relacionamento, especificando a quantidade a ser comprada ( que pode ser diferente da requisitada, por exemplo, para obter um desconto maior ou devido a alguma restrição de tamanho de lote de venda). Esta separação de funções implica na existência de dois relacionamentos distintos; o segundo é chamado de agregação porque o relacionamento de Materiais com Requisição é agregado em um pseudo CE, que por sua vez se relaciona com Pedidos através do relacionamento “Itens de pedidos”.

Relacionamento de Grau 3 - MER

Os exemplos vistos até agora são de relacionamento envolvendo dois CE´s. Eles são ditos binários ou de grau 2 e são os mais comuns na prática. O grau de um relacionamento é um número de CE´s envolvidos no relacionamento. A figura abaixo mostra um relacionamento de grau 3, ou triplo, entre professores, alunos e disciplinas.

A cardinalidade desse relacionamento, 1 : N : N, pode ser interpretada da seguinte forma:
- dado um professor e uma determinada disciplina temos diversos alunos;
- dado um professor e um determinado aluno, temos diversas disciplinas;
- dado um aluno e uma certa disciplina, temos um único professor;

A figura abaixo mostra um relacionamento triplo chamado MRP entre Materiais, Pedidos e Requisições, típico de um sistema de compras de materiais, onde requisições vindas de diversos setores são agrupadas em pedidos ou ordens de compra e se deseja relacionar cada pedido com as requisições originais. O relacionamento possui dois atributos: quantidade requisitada e quantidade pedida. O relacionamento tem cardinalidade N : N : N e é total do lado de Pedidos e de Requisições (toda requisição está associada a um ou mais pedidos e pode conter vários materiais, idem para pedidos), mas é parcial do lado de Materiais (um dado material pode não estar sendo comprado no momento).

Auto-relacionamentos - MER

Muitas vezes queremos fazer o relacionamento de um CE consigo mesmo. Por exemplo, dado o CE “Peças” queremos saber quais peças são componentes de uma dada peça ou, dada peça quais peças tem a têm como componente. Esses dois relacionamentos podem ser representados pelo diagrama da figura abaixo. Observe que cada uma das ligações do losango com o CE Peças recebeu um rótulo. O primeiro rótulo significa: “uma peça é um componente” de outra peça, e o segundo rótulo significa “uma peça tem como componente” outra peça. Os rótulos de ligações explicitam o papel que a peça desempenha no relacionamento, Este papel é normalmente evidente nos relacionamentos. Observe também que o relacionamento é de cardinalidade N;N, isto é, uma peça pode ter vários componentes e uma dada peça pode ser componente de várias peças.

Conjunto de Entidades Fracos - MER

Há casos em que a existência de um CE está vinculada à existência de outro CE. Um exemplo típico é o registro, para fins de seguro-saúde ou imposto de renda, dos dependentes de um funcionário. Nesse caso o registro só faz sentido para a empresa porque o dependente está ligado ao funcionário. Diz-se, então, que o CE “Dependentes” é um conjunto de entidades fraco. O CE funcionários é as vezes chamado conjunto pai conjunto mestre e dependentes é as vezes chamado de conjunto detalhe.

CE´s fracos não possuem um atributo determinante , mas em geral utilizam o atributo determinante do conjunto pai para construir o seu atributo determinante. Por exemplo, o atributo determinante de Dependentes poderia ser o par (numf, o-dependente).

CE´s fracos são representador no MER por um retângulo de borda dupla e seu relacionamento com o conjunto pai por um losango também de borda dupla.

Atributos de Relacionamentos - MER

Relacionamentos podem ter atributos. Por exemplo, o relacionamento N:N para indicar a associação de Materiais com seus Fornecedores pode indicar para cada par do relacionamento, o preço, o prazo e lote (quantidade) que o fornecedor estabelece para fornecer o material. A Figura abaixo mostra a representação gráfica desse relacionamento.

Poderíamos questionar nesse exemplo se um dado atributo, digamos, preço, pertence de fato ao relacionamento em vez de a um dos conjuntos de entidades envolvidos. Um teste simples é capaz de esclarecer a dúvida. Fixe o material e varie o fornecedor: se o preço varia, então o atributo não é do material; em seguida, fixe o fornecedor e varie o material: se o preço varia, então o atributo não é do fornecedor. Fica claro, nesse caso, que o atributo preço é do relacionamento, isto é, cada par (material, fornecedor) possui um preço. Idem aos atributos prazo e lote.

Relacionamento M:N (ou N:N) - Relacionamento entre Entidades | MER

Ocorre sempre que uma entidade se relacionar com várias tuplas de outra entidade e esta, por sua vez, relacionar-se com várias tuplas daquela entidade.

Esse relacionamento somente é possível na modelagem lógica de dados, uma vez que não se consegue implanta-lo em banco de dados relacionais. Ele será transformado em dois relacionamentos: um para muitos (1:n) e uma Entidade Associativa Atributiva será identificada, caso haja outras informações que devam ser agregadas a esta nova entidade – por exemplo de item de pedido em que se identificam quantidade e preço, ou criada, caso seja a simples união das chaves primárias de ambas as entidades – caso de vários produtos serem fornecidos por vários fornecedores e vice-versa.Esses relacionamentos são facilmente encontrados e normalmente são opcionais em ambas entidades. Existem casos em que há opcionalidade de apenas em uma das duas direções.

Nos exemplos a seguir, cada Música é composta por um ou vários Autores, e cada Autor pode compor uma ou várias Músicas. Cada Produto é fornecido por vários Fornecedores e cada Fornecedor pode fornecer vários Produtos. E, finalmente, cada Aluno é inscrito em uma ou várias Matérias e cada Matéria possui vários Alunos.

Neste exemplo, se uma entidade de um CE está associada a várias outras entidades de outro CE e vice-versa. só pode estar associada a uma única entidade de outro CE e vice-versa, dizemos então que o relacionamento é de cardinalidade N para N ou N:N.

Relacionamento 1:N (ou N:1) - Relacionamento entre Entidades | MER

Ocorre sempre que uma entidade se relacionar com uma ou mais tuplas da outra entidade e esta outra se relacionar apenas com uma tupla daquela entidade.

Esse relacionamento é mais comum e fácil de ser analisado. Nesse caso, a parte onde o relacionamento é 1 contém os dados básicos da entidade (pois é a chave primária dessa entidade) e o lado muitos fará parte da lista de atributos não chave.

Relacionamentos desse tipo raramente são obrigatórios em ambas as entidades. A exceção é quando se trata de itens de uma entidade, como itens de nota fiscal ou pedidos. Mas esse parece ser um caso especial de muitos para muitos.

A seguir, exemplos em que isso ocorre: Cada Gravadora grava vários CDs e cada CD é gravado apenas por uma Gravadora. Cada Cliente possui vários Pedidos e cada Pedido é de um único Cliente.

Neste exemplo, vários funcionários podem estar lotados num único departamento. Dizemos então que o relacionamento Lotações de Funcionários com Departamento é de cardinalidade N para 1 ou N : 1.

A cardinalidade do relacionamento está indicada pelos símbolos N e 1. Para determinar sua posição correta pode-se usar o seguinte argumento: “um funcionário existe em um único departamento e em um único departamento podem existir vários funcionários”.

Relacionamento 1:1 - Relacionamento entre Entidades | MER

Ocorre sempre que uma entidade tiver uma única ocorrência para cada ocorrência na outra entidade.

Sempre que houver esse relacionamento, deve-se perguntar se realmente são duas entidades distintas ou se elas podem ser unidas. Normalmente, ao checarmos a chave de ambas as entidades, chegamos facilmente à conclusão se as entidades devem ou não ser unidas. Da mesma forma, deve-se perguntar se esse relacionamento sempre será um para um ou se existe a possibilidade de, amanhã, vir a ser um para muitos.

Note que esse relacionamento é efetivamente raro. Relacionamentos em que seja obrigatória em ambas as entidades são mais raros ainda.

No exemplo a seguir, cada departamento é gerenciado por um gerente, e cada gerente gerencia um departamento. As chaves são distintas (são objetos absolutamente diferentes), mas é interessante nos questionarmos, mesmo que eventualmente, se um gerente não pode gerenciar mais de um departamento. Isso pode ou não ocorrer, dependendo da empresa, mesmo que seja por um curto período de tempo. Nesse caso, o relacionamento deveria ser trocado para um para muitos (1:n);

Isso também ocorre com o relacionamento entre Computador e Para Mãe. Essa pergunta deve ser feita à possibilidade de um computador possuir mais de uma Placa Mãe no futuro.

Neste exemplo, se uma entidade de um CE só pode estar associada a uma única entidade de outro CE e vice-versa, dizemos então que o relacionamento é de cardinalidade 1 para 1 ou 1:1.

Relacionamento entre Entidades | MER

Para relembrar:
MER - Modelo Entidade x Relacionamento

Sempre que duas entidades apresentarem interdependência (por exemplo, autor da música ou música do CD), indica-se um relacionamento entre elas. Deve-se perguntar a cada par de entidades se elas se relacionam. Para facilitar esse trabalho, siga o esquema abaixo:

Cada entidade 1 {deve ter ou pode ter} relacionamento {uma ou mais ou uma única} entidade2

Assim, podemos dizer que:
1 – Cada CD deve ser gravado por uma única gravadora;
2 – Cada gravadora pode ter gravado um ou mais CDs;

1 – Cada autor pode ter escrito uma ou mais músicas;
2 – Cada música pode ser escrita por um ou mais autores;

1 – Cada música pode estar gravada em um ou mais CDs.
2 – Cada CD deve conter uma ou mais músicas.

Conforme você pode notar, cada relacionamento contém um nome (normalmente um verbo como ser gravado, conter, ter escrito), a determinação de opcionalidade (deve ou pode) e um grau ou cardinalidade (uma única ou uma ou mais).

Análise dos tipos de Relacionamentos (Cardinalidade)

Há três tipos de relacionamentos:
- Um para um (1:1);
- Um para Muitos (1:n);
- Muitos para muitos (m:n);

Tipos de Atributos e Diagramas

Um atributo pode conter vários subatributos. Nesse caso ele se diz itens de grupo ou composto. Por exemplo:

Atributo: endereço
Subatributos: Local (Rua, Número, Complemento), Cidade, CEP.

A representação gráfica desse atributo composto é:

Funcionário (numf, RG, CPF, nome, end(rua, número, complemento, cidade, cep), salário)

Se um atributo de uma entidade pode tomar diversos valores então se diz multivalorado. Por exemplo:

Atributo: Telefone
Valores:
(99) 9999-9999
(44) 4444-4444

Essa propriedade pode ser indicada colocando-se um * após o nome do atributo multivalorado.

Funcionário (numf, nome, telefone*)

Convenção para utilização em Diagramas

Deve-se utilizar uma caixa de qualquer dimensão com um nome único (exclusivo) em cada uma das caixas. Esses nomes devem representar as Entidades do sistema. Alguns autores preferem utilizar a caixa com bordas arredondadas. Isso é apenas uma convenção diferente, que em nada modificará o objetivo e a compreensão da Entidade.

A seguir será utilizado o nome da Entidade de fora da caixa e separada a Chave primária dos demais atributos com uma linha horizontal:

Atributos | Chaves - Primária, Secundária e Estrangeira

É um atributos utilizado para indexar dados. Há três tipos de chaves:

• Primária
• Estrangeira;
• Secundária;

Chave primária
É o atributo que permite identificar uma única ocorrência de uma tupla em uma Entidade. Dessa forma, seu conteúdo deve ser único, exclusivo e imutável para cada linha dessa Entidade. Todos os demais atributos da entidade devem depender unicamente desse atributo.

Caso não exista um atributo que possa assumir a posição de chave primária, é preciso criá-lo. Veja que nem todos campos é uma boa chave. Normalmente utilizamos campos numéricos por serem localizados mais rapidamente pelos bancos de dados. Valores alfanuméricos grandes têm acesso mais lento.

Dessa forma, fica claro que toda tabela deve conter uma chave primária. Muitas vezes encontramos o termo super-chave para identificar a chave primária. Trata-se apenas de um nome diferente para designar a mesma coisa, e, portanto não é preciso se preocupar com isso.

Eventualmente uma chave primária pode conter mais de um atributo. Nesse caso, a chave conterá mais de um atributo, mas será considerada a chave da tabela. A união dos dois atributos é que deve garantir o acesso a uma única linha da entidade. Esse caso de chave primária é chamado de Chave Concatenada.

Chave estrangeira
É o atributo que estabelece a relação de uma Entidade com a Chave Primária de outra Entidade e permite uma relação entre entidades. Isto ocorre quando uma Entidade dependente herda a chave da Entidade Fundamental exatamente para estabelecer o relacionamento entre elas.

Chave Secundária

Esta chave é utilizada como meio de classificação e pesquisas em entidades. Sempre que houver a necessidade de buscar informações semelhantes, em ordem crescente ou decrescente, em função de datas, valores ou status predefinidos, criam-se chaves secundárias.

Podem também ser concatenadas a outras chaves secundárias para extrair a informação desejada.

O que são Atributos? | Modelagem de Dados

Os atributos são informações básicas que qualificam uma entidade e descrevem seus elementos ou características. Quando transpostos ao modelo físico (ao banco de dados), chamamos os atributos de campos ou colunas.

Note que todas as entidades devem possuir os atributos necessários ao andamento das operações da empresa, do contrário a entidade não será necessária para o sistema. Esses atributos devem representar o objeto na sua totalidade.

Há uma tendência a confundir Entidade e Atributo. Tenha sempre em mente que um Atributo é uma característica, logo não contém um grupo de informações. Por sua vez, uma Entidade sempre é um grupo. No mínimo são necessários dois atributos para criar uma entidade. Uma entidade com um único atributo normalmente será agregada a outra entidade existente ao modelo.

Exemplos de atributos as entidades:
- Entidade Pessoa: nome, endereço, documento, data de nascimento, telefone, e-mail;
- Entidade Nota Fiscal: série, número, data e emissão e cliente;

Nota-se, portanto, que ao utilizarmos o conceito de atributos em entidades estamos querendo qualificar ao máximo aquele objeto do mundo real. Essas informações muitas vezes não correspondem a todas as informações possíveis daquele objeto, mas sim às informações relevantes para o funcionamento do sistema.

No exemplo do catálogo de CDs, não teremos cada um dos CDs armazenados no banco de dados, mas sim as características que nos permitirão identificar qual CD o cliente quer comprar, quais músicas há naquele CD, autores, gravadoras etc. Não importa se há várias unidades do mesmo CD disponíveis para venda na loja (a menos que se esteja desenvolvendo um sistema que controle o estoque cd CDs). Esta deve ser uma preocupação quando estivermos desenvolvendo um novo sistema – até onde exatamente queremos
chegar com o sistema.

Um atributo chave é um dos atributos de um CE especialmente projetado para identificar de forma única qualquer entidade do CE.`É importante enfatizar a expressão acima especialmente projetado, porque a unicidade do valor do atributo determinante deve ser garantida para qualquer conteúdo futuro do CE e não apenas para a instancia atual do CE. Resumindo: um CE fica especificado no modelo entidade-relacionamento, dado o nome do CE, os nomes dos atributos do CE, os nomes do CE e dentre esses o nome do atributo chave. Uma forma textual de definir um CE poderia ser, por exemplo:

Funcionário (numf, RG, CPF, nome, end, salário)

Tupla
É uma estrutura de atributos intimamente relacionados e interdependentes que residem em
uma entidade. Quando transposta ao modelo físico, uma tupla equivale a um registro ou linha da tabela.

O que é Entidade? | Modelagem de Dados

Entidade é um agrupamento lógico de informações inter-relacionadas necessárias para a execução das atividades do sistema. Uma entidade normalmente apresenta um objeto do mundo real ou, quando não é, contém informações relevantes às operações da empresa. Quando transposta ao modelo físico (ao banco de dados), chamamos a entidade de tabela. Uma entidade é entendida como um objeto concreto ou abstrato do sistema. São informações necessárias e que, portanto, devem ser armazenadas.

Ao transpor o Modelo Relacional a um modelo Orientado a Objeto, a Entidade passa a ser uma Classe ou categoria do objeto ao qual agregaremos os respectivos métodos. Ao transpor o Modelo Relacional a um modelo Orientado a Objeto, a Entidade passa a ser uma Classe ou categoria do objeto ao qual agregaremos os respectivos métodos. Cada entidade deve conter múltiplas ocorrências ou instâncias do objeto que representa. Isso não permitirá incorrer no erro de confundir a Entidade com a Instância. A entidade é a classe ou categoria (CD), e a instância é um objeto específico (no exemplo: Mais do Mesmo
ou Bate-Boca).

Em resumo, podemos dizer que uma entidade é tudo aquilo que pode ser individualizado e que possui existência própria (física ou abstrata). As entidades são caracterizadas por algumas propriedades específicas denominadas atributos. Cada atributo possui um nome e um valor específico para a entidade.

Um conjunto de entidades (CE) é um conjunto matemático no sentido de que todos os seus elementos são distintos, e não existe nenhuma ordem intrínseca entre eles. Isto implica que valores correspondentes dos atributos de duas entidades não podem ser todos iguais. Em outras palavras, a lista de atributos de um CE deve ser suficiente para caracterizar completamente qualquer entidade do conjunto.

Exemplo: Suponhamos que queremos registrar para um conjunto de pérolas as seguintes informações: cor, diâmetro, peso, lote; elas podem não ser suficiente para distinguir duas pérolas que podem ter os mesmos valores para cor, diâmetro, peso e lote. Se quisermos que essas pérolas façam parte de um conjunto de entidades, algumas propriedades teriam que ser incluídas, como local da extração, empresa, pescador etc. Um exemplo mais realista é o caso de itens fabricados em série cujos atributos mensuráveis são idênticos; nessa caso é comum distingui-los através de um número de série impresso no item – um atributo chave
(chave primária).

Exemplos de Entidade:

Entidades Associativas
Há um caso específico para as Entidades Associativas: sempre que, além do simples relacionamento entre as duas entidades fundamentais, houver outras informações específicas da nova entidade criada (como, por exemplo, a quantidade e o valor entre pedido x produto ou bimestre, nota e faltas do aluno x matéria), ela será chamada de entidade Associativa Atributiva.

No catálogo de CD dado como exemplo, podemos identificar facilmente duas entidades: CD e Música. Observando com mais cuidado, vê-se que Gravadora e Autor também possuem uma estrutura independente. Isso porque há outras informações que, apesar de não estarem descritas na planilha, são de fato apenas da Gravadora e do Autor. Exemplo: endereço, data de nascimento, telefone etc. Para isso é importante entender o que são os atributos (características) de uma Entidade.

Objetivos da Modelagem de Dados

O principal objetivo da Modelagem de Dados é desenvolver um modelo que, contendo entidades e relacionamentos, seja capaz de representar os requerimentos das informações do negócio. Veja o que poderia ser um exemplo de catálogo de CDs:

Um dos principais problemas relacionados com bancos de dados é redundância (repetição) de informações. Sempre que houver duas informações, nunca se saberá em qual delas pode confiar.

Imagine que na tabela exemplo alguém altere o nome do CD apenas na linha 2 para “Mais ou Menos”. Qual dos nomes estaria correto? É por isso que devemos criar um banco de dados com um mínimo de redundância, evitando esse problema.

Exatamente para evitar a redundância é que se cria uma série de tabelas no banco de dados, e não apenas uma. Naturalmente isso aumenta a complexidade da operação, mas traz uma enorme vantagem ao evitar a redundância.

Um outro objetivo é a economia de espaço. Quando se admite a redundância, é muito comum ter que repetir nomes, descrições, datas etc. Ao isolarmos essas informações em tabelas distintas e ao relacionarmos as tabelas por um código comum estamos economizando espaço de armazenamento.

No exemplo anterior, identificamos que há diversos dados redundantes: Código do CD, Nome do CD, Nome da Gravadora, preço, autor. Além do mais, a simples repetição desses campos representa um espaço gasto sem necessidade. Podemos separar as informações em mais de uma tabela, armazenando apenas uma vez cada informação distinta e relacionando as tabelas.

Exemplo: podemos criar uma tabela para armazenar os dados dos CDs (Codigo do CD, Nome do CD, Nome da gravadora e preço) e outra para armazenar as Musicas (Número da faixa, Nome, Autor e Tempo). Basta acrescentar o código do CD em Músicas e teríamos uma relação entre Música e CD. Contudo, somente isso não é suficiente.

Abordagem Relacional: o Modelo de Entidade x Relacionamento (MER)

A Abordagem Relacional é a utilização de conceitos de Entidade e Relacionamento para criar as estruturas que irão compor o banco de dados. Partindo sempre da necessidade do usuário ou grupo de usuários do sistema, iniciamos a pesquisa das necessidades de informações desses usuários.

A definição do escopo do sistema é, portanto, importante para o início do trabalho de análise de dados.

É comum no início do desenvolvimento de um sistema que não tenhamos a noção exata da tarefa a ser realizada. O maior erro nessa fase é admitir que já sabemos o que deve ser feito, seja por experiência anterior, seja por falta de tempo para conversar com os usuários do sistema.

Para minimizar esse problema, devemos criar uma estrutura gráfica que permita identificar as Entidades de um sistema e como estas se relacionam.

Nessa fase é importante saber quais informações são importantes para o sistema e que deve ser armazenado. A esta representação gráfica dá-se o nome de Modelo de Dados.

Devemos notar que o Modelo de Dados dará suporte a toda a empresa, incorporando as informações necessárias para o andamento dos negócios. Ele será composto de Entidades e Relacionamentos, daí ser conhecido por Modelo de Entidade x Relacionamento (MER).

Vantagens na utilização do Modelo de Entidade x Relacionamento:

• Sintaxe mais robusta: o modelo documenta as necessidades de informação da empresa de maneira precisa e clara;
• Comunicação com usuário: os usuários podem, com pouco esforço, entender o modelo;
• Facilidade de criação: os analistas podem criar e manter um modelo facilmente;
• Integração com várias aplicações: diversos projetos podem ser inter-relacionados utilizando-se o modelo de dados de cada um deles.
• Utilização universal: o modelo não está vinculado a um banco de dados espedífico, mas sim ao modelo da empresa, o que garante sua independência de implementação.

Introdução ao Banco de Dados Relacional

Dados relacionados entre si. É uma característica fundamental dos bancos de dados modernos, ou seja,
permite o inter-relacionamento existente entre os dados e a aplicação de regras de consistências, outra característica fundamental é a atomicidade – requisito de que certas operações sobre os dados devem ser feitas de forma conjunta e indivisível a fim de preservar a consistência da base de dados mesmo na presença de falhas no equipamento ou na comunicação com a base de dados.

Bases de dados usualmente requerem o acesso simultâneo ou concorrente por vários usuários, cujas operações podem interagir gerando inconsistências, como por exemplo, a aquisição de uma passagem aérea para dois passageiros distintos.

Tabelas

Tabelas são depósitos de informações, que podem ser entendidas como um conjunto de linhas e colunas. As colunas de uma tabela qualificam cada elemento (no caso, a linha) com informações relacionadas ao objeto. As tabelas são organizadas de modo a receber e manter as informações de determinadas entidades. Devemos manter em tabelas todos os atributos da entidade em questão.

Banco de Dados Livres vs Banco de Dados Proprietários

Quando estamos implantando um banco de dados, às vezes, nos deparamos com a dificuldade de escolher um banco de dados correto para a nossa empresa. É difícil, de uma hora para outra saber qual o melhor banco a ser adotado. Temos que considerar diretamente o quanto (valor) a empresa está disposta a investir em no sistema de informação, qual o número de usuários que irão se conectar simultaneamente, a possibilidade de expansão da empresa para outros sites, quantas filiais a empresa possui, se o banco de dados vai ser centralizado ou distribuído, quantidade de dados armazenado em um determinado período etc.

Não tem como julgar simplesmente que um banco de dados é melhor que o outro antes de analisar qual a verdadeira necessidade da empresa. Dentro dos banco de dados comerciais, os mais conhecidos e utilizados são Oracle, MS SQL Server, UDB IBM DB2, MS Access, Informix etc. Já os banco de dados livres encontram-se o MySQL, Firebird e PostgreSQL.

Hoje, por causa da grande perda de mercado para os bancos de dados livres, os fabricantes de banco de dados comerciais resolveram criar a versão “EXPRESS” dos seus bancos de dados comerciais, que geralmente são limitados pelo número de processadores suportados, pela quantidade de memória suportada e pelo tamanho em disco do banco de dados, porém, com custo “ZERO” dessas versões.

Geralmente, as versões expressas são totalmente compatíveis com as versões comerciais, sendo muito fácil sua migração para a versão comercial.

Detalhes e características do SQL Server 2005 Express podem ser encontradas em:
http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx

Detalhes e caracteristicas do DB2 Express podem ser encontradas em:
http://www.ibm.com/br/businesscenter/catalogo/db2_express-c.phtml

Detalhes e características do SQL Servwe 2008 Express podem ser encontradas em:
http://msdn.microsoft.com/pt-br/library/ms143685(v=sql.100).aspx
http://blogs.msdn.com/b/sqlexpress/archive/2010/04/21/database-size-limit-increased-to-10gb-in-sql-server-2008-r2-express.aspx

Aplicações em Quatro Camadas - Banco de Dados

Esse modelo é uma atualização do modelo de três camadas, tendo a principal ideia de tirar a camada de apresentação do cliente e centralizá-la em um determinado ponto, sendo a grande maioria dos casos um servidor web (iis, apache, etc). Para isso, o acesso aos programas não são mais instalados nos clientes e sim acessados através de browsers, como o internet explorer, o firefox, o netscape navegator etc. Com isso, os clientes não precisam ser instalados maquina a maquina. As camadas são: cliente, que são os browsers; a camada de apresentação, que geralmente está alocada no servidor web, podendo ser composta de páginas HTML, ASP, PHP etc; camada lógica, que são alocadas as regras de negócio e a camada de dados, onde temos o servidor de banco de dados.

Aplicações em Três Camadas - Banco de Dados

A principal ideia desse modelo é a retirada das regras de negócio do cliente e centralizá-la em um determinado ponto, o qual é chamado de servidor de aplicação. O acesso ao banco de dados é feito por esse servidor de aplicação. A grande vantagem desse modelo em relação ao modelo Cliente/Servidor é a atualização do servidor de aplicação em um único ponto, não necessitando trocar os executáveis de todas as estações. Com isso, a camada de apresentação continua nos clientes, a camada de lógica (regras de negócio) ficam em um servidor e a camada de dados (banco de dados) ficam em outro ponto, facilitando uma boa parte da manutenção.

Processamento distribuído

Processamento distribuído significa que máquinas diferentes podem estar conectadas entre si em uma rede de computadores como a internet, de tal modo que uma única tarefa de processamento de dados possa se estender a várias máquinas na rede. A comunicação entre as várias máquinas é efetuada por algum tipo de software de gerenciamento de rede.

Segundo o Wikipedia, um sistema de processamento distribuído ou paralelo é um sistema que interliga vários nós de processamento (computadores individuais, não necessariamente homogéneos) de maneira que um processo de grande consumo seja executado no nó "mais disponível", ou mesmo subdividido por vários nós. Conseguindo-se, portanto, ganhos óbvios nestas soluções: uma tarefa qualquer, se divisível em várias subtarefas pode ser realizada em paralelo.

Arquitetura Cliente/Servidor e Aplicações de Duas Camadas

O modelo Cliente/Servidor teve como principal objetivo descentralizar o processamento centralizado que dominava na época dos mainframes. Com isso, parte do processamento é executado no cliente e parte no servidor.

Para esse modelo, é utilizado aplicações de duas camadas, permanecendo o código executável do aplicativo desenvolvido nos clientes e o banco de dados em um servidor (geralmente dedicado).

O Cliente desse modelo é responsável pela Apresentação e lógica de negócios. O servidor de banco de dados (segunda camada, o servidor) é responsável pela persistência dos dados que a aplicação cliente envia.

Um grande problema desse modelo é a atualização dos clientes nas estações. Um bom exemplo disso seria uma grande empresa que possui mais de 1000 estações e que precisa atualizar o aplicativo cliente! (Fazer esse serviço manualmente não é nada produtivo!)

Características de um Gerenciador de Banco de Dados

Controle de redundância: informações devem possuir um mínimo de redundância visando estabelecer à estabilidade do modelo;

Compartilhamento de dados: as informações devem estar disponíveis para qualquer número de usuários de forma concomitante e segura;

Controle de acesso: necessidade de saber quem pode realizar qual função dentro do banco de dados;
Esquematização: os relacionamentos devem estar armazenados no banco de dados para garantir a facilidade de entendimento e aplicação do modelo. A integridade das informações deve ser garantida pelo banco de dados;

Backup ou cópias de segurança: deve haver rotinas específicas para realizar a cópia de segurança dos dados armazenados;

A segurança é um fator que muito diferencia um banco de dados de outro. Às vezes, há dois bancos de dados que utilizam o SQL como linguagem de acesso e manipulação de dados, mas que têm estruturas de controle de acesso completamente diferentes. Um gerenciador de banco de dados deve prever o controle de acesso às informações e garantir por meio de recursos internos que os dados sejam disponibilizados rapidamente.

O objetivo de um banco de dados relacional é armazenar um grupo de objetos de um dicionário de dados, de forma a tornar rápida e segura a manipulação das informações contidas nesses objetos. Como objetos, podemos entender tabelas, visões, índices e até mesmo procedimentos e funções que estejam armazenadas no banco de dados.

A Evolução dos Softwares

Em 1847 foi criada a álgebra booleana e passados quase um século, em 1945 Von Neumann criou a Lógica Binária, logo após nasce, também, a Primeira Geração da Linguagem de Máquina, seguida pela Segunda Geração da Linguagem de Programação em 1955, a Linguagem Assembler.

No Final da década de 50, foi criada a FORTRAN, linguagem de Terceira Geração de alto nível, e após isso, em 63 o Basic, popularizado nos microcomputadores e já em 1968, a Linguagem Pascal. Em 1975, ocorreu o início das Linguagens de Quarta Geração (4GL), e na mesma época o Smalltalk do Centro de Pesquisas da Xerox. Já em 1978, foi criado o Ada, introduzido pelo DoD e baseado no FORTRAN e Pascal.

No início dos anos 80 foi criado o MS-DOS da Microsoft, para PC e Compatíveis, seguidos pelo MS Word e do Windows como Ambiente Operacional, em 83 e 85, respectivamente. Não ficando atrás, surge em 1990 o Unix, firmando-se como ambiente multiusuário.

Logo após o nascimento dos primeiros prototipadores é instaurado o Windows 3.1 e 3.11, já com características de integração em rede. E a partir de 1993 nasce o Windows NT iniciando disputas por ambientes de rede com a Novell. Em 1995 e 1996, são criadas linguagens visuais (Visual Objects, Visual Basic e Delphi) disputando o ambiente de programação visual, seguidos pela criação de ferramentas
de prototipação para VB e Delphi.

Origens e Histórico dos computadores

A Evolução dos computadores antigamente dava-se de forma lenta, visto que ainda não se entendia muito bem a necessidade de um computador eletrônico. Passados os anos 1930, essa ideia sofreu algumas modificações, sendo a computação eletrônica restrita a apenas a algumas pessoas.

A partir da década de 60 a programação das máquinas ganhou certa importância, surgindo reais necessidades disseminadas pelo desenvolvimento das máquinas e do software. Desde então, os equipamentos computacionais e programas vem passando uma série de rápidas transformações, atingindo um patamar de maior facilidade para o usuário final.

O soroban, o ábaco japonês era destinado a registrar valores e realizar operações de soma e subtração, e posteriormente foram-se desenvolvidas as técnicas para divisão e multiplicação, e atualmente é possível realizar extrações de raízes, sendo possível trabalhar com números inteiros, decimais e negativos.

No Brasil, o Ábaco chegou em 1908, com os primeiros imigrantes, e teve uma versão moderna em 1953, tendo sua técnica de manuseio alterada pelo Prof. Fukutaro Kato em 1956.

O ábaco tem por sua origem o método de calcular usando sulcos de areia e pequenas pedras, sendo posteriormente substituída a areia, por uma tábua de argila, e depois, orientada por uma haste que as trespassava.

Introdução à Banco de Dados

Um banco de dados é um conjunto coerente e lógico de dados relacionados que possuem significância intríseca. Esses dados representam aspectos do mundo real e devem ser mantidos para atender aos requisitos da empresa.
Esses dados estão dispostos em uma ordem predefinida para atender a determinadas necessidades dos usuários. Existem diversos objetos que podem ser armazenados em um banco de dados, como índices, visões, procedimentos e funções.

Segundo DATE (p. 41, 2000), o objetivo geral do SGDB é fornecer suporte ao desenvolvimento e à execução de aplicações de bancos de dados. Portanto, sob um ponto de vista de mais alto nível, um sistema de banco de dados pode ser considerado como tendo uma estrutura muito simples em duas partes, consistindo em um servidor (também chamado back end) e um conjunto de clientes (também chamados front ends).

O servidor é o próprio SGDB, emitindo as funções de manipulação de dados, segurança, definição de dados, integridade de dados etc.
Os clientes são as diversas aplicações executadas sobre o SGBD, tanto aplicações escritas por usuários quanto aplicações fornecidas pelo fabricante do SGBD ou produtores independentes. (DATE, p. 41, 2000)

Um gerenciador de banco de dados (DBMS – Database Management System) é uma coleção de programas que permitem criar estruturas, manter dados e gerenciar as transações efetuadas em tabelas, além de permitir a extração das informações de maneira rápida e segura.

Ao se projetar um banco de dados tem-se em mente um conjunto de aplicações que primordialmente se deseja fazer sobre os dados. Elas determinam o uso principal que se quer fazer do banco de dados. Bancos de dados podem ser muito simples ou muito complexos e/ou de tamanhos que podem variar de um banco de dados para outros.

Como, por exemplo, podemos ter uma simples e pequena base de dados dos nomes e telefones das pessoas conhecidas de um indivíduo ou dos bens e valores de uma pessoa física. Bases de dados podem ser mantidas de forma manual, através de um arquivo físico ou de forma automática através de um computador. Uma base de dados maior e mais complexa poderia ser, o catálogo de todos os livros publicados nos Estados Unidos ou uma base de dados de todas as fotos recolhidas ao longo dos anos pelo programa espacial americano.

Há cinco tipos de banco de dados:

• Hierárquico: um gerenciador desse tipo representa dados como uma estrutura de arvore,composto de uma hierarquia de registros de dados.
• Rede: Representa os dados como registros vinculados uns aos outros, formando conjuntos comuns de dados. Existe uma similaridade muito grande entre o modelo hierárquico e o modelo de rede. Pode-se entender o modelo de rede como uma generalização do modelo hierárquico, ou este último como um caso particular do modelo de rede. No modelo de rede, um filho pode ter mais de um pai.
• Relacional: representa os dados como uma simples coleção de linhas e colunas em tabelas bidimensionais.
• Objeto-Relacional: combina o modelo orientado a objetos (união de propriedades e métodos) com o modelo relacional (linhas e colunas de tabelas).
• Objeto: representa os dados e processos em um único objeto. Aplicações escritas pelo usuário são basicamente programas aplicativos comuns em uma linguagem de programação convencional de terceira geração (L3G).

Aplicações fornecidas por fabricantes (chamadas frequentemente de ferramentas – tools) tem finalidade básica de auxiliar na criação e execução de outras aplicações. Por exemplo, uma das ferramentas fornecida pelo fabricante será um gerador de relatórios. Qualquer solicitação de relatório pode ser considerada um pequeno programa aplicativo, escrito em uma linguagem de geração de relatórios de nível muito alto.

As ferramentas fornecidas pelo fabricante podem ser divididas em diversas classes:

a. Processadores de linguagem de consulta.
b. Geradores de relatórios.
c. Subsistemas gráficos de negócios.
d. Planilhas eletrônicas.
e. Processadores de linguagem natural.
f. Ferramentas para gerenciamento de cópias ou “extração de dados” (DATE, p. 42, 2000)

Utilitários
São programas projetados para auxiliar o DBA com diversas tarefas administrativas. Exemplos:

a. Rotinas de carga, a fim de criar a versão inicial do banco de dados a partir de um ou mais arquivos do sistema operacional.
b. Rotinas de descarregamento/recarregamento, a fim de descarregar o banco de dados, ou partes dele, para o meio de armazenamento de backup e recarregar dados dessas cópias de backup.
c. Rotinas de reorganização, a fim de rearranjar os dados no banco de dados armazenado por várias razões (em geral, relacionada com o desempenho)
d. Rotinas estatísticas, a fim de calcular diversas estatísticas de desempenho, tais como
tamanhos de arquivos e distribuição de valores de dados. (DATE, p. 43, 2000)

O que é um sistema de informação?

Um sistema de informação é um tipo especializado de sistema e pode ser definido de inúmeros modos. Para nosso propósito, um sistema de informação (SI) é uma série de elementos ou componentes inter-relacionados que coletam (entrada), manipulam e armazenam (processo), disseminam (saída) os dados e fornecem um mecanismo de feedback.

Entrada
Em sistemas de informação, a entrada é a atividade de captar e juntas os dados primários. Ao se produzir cheques de pagamento, por exemplo, as horas trabalhadas de cada empregado devem ser coletadas antes que o cheque de pagamento possa ser calculado ou impresso. A entrada pode tomar muitas formas. E um sistema de informação projetado para produzir cheques de pagamento, por exemplo, os cartões de horas dos empregados poderiam ser a entrada inicial. No sistema telefônico 911, um telefonema recebido seria
considerado uma entrada. A entrada de um determinado sistema de informação de marketing poderia ser uma pesquisa ou respostas de uma entrevista. Note que independentemente do sistema envolvido, o tipo de entrada é determinado pela saída desejada do sistema.
A entrada pode ser um processo manual ou automatizado. Um scanner em uma mercearia que lê códigos de barras e apresenta o item de mercearia e o preço em uma caixa registradora computadorizada é uma forma de entrada computadorizada. Independentemente, para se atingir a saída desejada, a entrada precisa é fundamental.

Processamento
Em sistemas de informação, o processamento envolve a conversão ou transformação dos dados em saídas úteis. O processamento pode envolver cálculos, comparações e tomada de ações alternativas, e armazenagem dos dados para uso futuro.
O processamento ode ser feito manualmente ou com um a assistência de computadores. No aplicativo de folha de pagamento, as horas trabalhadas de cada empregado devem ser convertidas em pagamento líquido. O processamento necessário pode envolver, primeiro, a multiplicação das horas do empregado, para se obter o pagamento bruto. Se horas semanais trabalhadas superam 40 horas, o pagamento de horas extras também pode ser determinado. Por exemplo, taxas federais e estaduais podem ser mantidas ou subtraídas do pagamento bruto; muitos empregados têm seguros de saúde e de vida, planos de poupança e outras
deduções que também devem ser subtraídas do pagamento bruto para se obter o pagamento líquido.

Saída
Em sistemas de informação, a saída envolve a produção de informações úteis, geralmente na forma de documentos, relatórios e dados de transações. As saídas podem incluir cheques de pagamento a empregados, relatórios para gerentes e informações fornecidas a acionistas, bancos, agencias governamentais e outros grupos. Em alguns casos, a saída de um sistema pode se transformar em entrada para outro. Por exemplo: a saída de um sistema que processa pedidos de venda pode ser usada como entrada para controlar outros como entrada de um sistema de faturamento de clientes.
A saída pode ser produzida de várias formas. Para um computador, as impressoras e as configurações de tela são dispositivos de saídas comuns. A saída pode também ser um processo manual envolvendo relatórios e documentos manuscritos.

Feedback
Em sistemas de informação, feedback é uma saída usada para fazer ajustes ou modificações as atividades de entrada ou processamento. Por exemplo, erros ou problemas podem fazer com que os dados d entrada sejam corrigidos ou que um processo seja modificado. No nosso exemplo de uma folha de pagamento. Talvez o número de horas trabalhadas de um empregado tenha entrado no computador como 400 horas, em vez de 40. Felizmente, a maioria dos sistemas de informação checa para dar certeza de que os dados caíram dentro de certas faixas predeterminadas. Para as horas trabalhadas, a faixa poderia ser de 0 a 100 horas, É improvável que um empregado trabalhe mais de 100 horas em uma semana. Neste caso, o sistema de informação determina que 400 horas, é fora do alcance e fornece um feedback, tal como um relatório de erro. O feedback é usado para checar e corrigir a entrada do número de horas trabalhadas para 40. Se não detectado, este erro resultaria em um pagamento líquido muito alto impresso no cheque de pagamento.
O feedback também é importante para os administradores e tomadores de decisão. Por exemplo, uma saída de um sistema de informação poderia indicar que os níveis do estoque para alguns itens estão ficando baixos. Os administradores poderiam usar esta saída para a decisão de pedir mais estoque, fornecendo assim um feedback. Os novos pedidos de estoque então se tornam entradas do sistema.

O que é um sistema?

Sistema é um conjunto de elementos ou componentes que interagem para se atingir objetivos. Os próprios elementos e as relações entre eles determinam como o sistema trabalha.

Como por exemplo, tomemos o processo de assar bolo.

É óbvio, as entradas tangíveis para o bolo são a farinha, ovos, açúcar, manteiga, etc. Tempo, energia, técnica e conhecimento também são necessários como entradas ao sistema. O tempo é investido na compra e medição dos ingredientes; a energia é necessário para misturar os ingredientes e assa-los. O conhecimento definiria a proporção e a ordem na qual os ingredientes são misturados. A técnica seria a habilidade de entender e seguir as instruções de uma receita (a base do conhecimento).

Os mecanismos de processamento consistem, primeiramente, em combinar os ingredientes em uma vasilha, de modo que a mistura tenha uma consistência certa, e então assa-la em um espaço de tempo apropriado e em temperatura correta. Há um mecanismo de feedback (termostato) no forno. O forno liga e desliga para manter uma temperatura constante. A saída será o bolo acabado. É importante notar que elementos ou componentes independentes de um sistema interagem. Quando aquecidos, a farinha, ovos, o açúcar e a manteiga interagem para formar o bolo acabado.

Os sistemas podem ser relativamente simples, tal como o processo de assar o bolo, ou mais complexos. Lojas varejistas, hospitais, indústrias, mercados atacadistas e etc, todos podem ser vistos como sistemas. Os elementos do sistemas podem incluir maquinaria, empregados, gerenciamento e coisas do gênero. As entradas desses sistemas incluem trabalho, capital, terra, mercadorias, equipamentos e assim por diante. A saídas desses sistemas são os bens e os serviços oferecidos pelas empresas. Na maioria desses casos, as metas do sistema são a maximização de lucros e a satisfação do cliente. Bons sistemas ajudarão sua organização atingir suas metas, aperfeiçoando os processos empresariais e adicionando valor aos seus
produtos (bens e serviços). Também é importante notar que alguns sistemas trabalham melhor do que outros. E alguns simplesmente não funcionam. Uma receita ruim ou uma linha de montagem mal projetada pode resultar em um bolo impossível de se comer ou em um carro que nunca funciona apropriadamente.

O valor da informação

O valor da informação está diretamente ligado à maneira como ela ajuda os tomadores de decisões a atingirem as metas da organização. O valor da informação poderia ser medido pelo tempo necessário para a tomada de uma decisão ou pelo aumento dos lucros da empresa. Exemplo: Os administradores decidem investir ou não em um sistema de informações e tecnologia adicionais. Um novo sistema de pedidos computadorizado pode custar R$30.000,00, mas isso pode gerar um adicional de  $50.000,00 em vendas. O valor adicionado pelo novo sistema é de R$20.000,00.

Características da boa informação:

Precisa: A informação precisa não tem erros. Em alguns casos, a informação imprecisa é gerada pela entrada de dados incorretos no processo de transformação. Isto é comumente chamado de entra lixo, sai lixo (ELSL).
Completa: A informação completa contém todos os dados importantes. Por exemplo: um relatório de investimentos que não inclui todos os custos importantes não está completo.
Econômica: A informação também deve ser de produção relativamente econômica. Os tomadores de decisões devem sempre fazer um balanço do valor da informação com o custo da sua produção.
Flexível: A informação flexível pode ser usada para as diversas finalidades. Por exemplo: a informação de quanto se tem de estoque disponível de uma determinada peça pode ser usado pelos representantes de vendas no fechamento de uma vendas, por um gerente de produção para determinar se mais estoque é necessário, e por um diretor financeiro para determinar o valor total em que a empresa tem investido em estoque.
Confiável: A informação confiável pode ser dependente: Em muitos casos, a confiabilidade da informação depende da confiabilidade dos métodos que são recolhidos os dados, ou seja, a confiabilidade depende da fonte da informação. Exemplo: Um boato vindo da fonte desconhecida que os preços de petróleo devem subir, podem não ser confiável.
Relevante: A informação relevante é importante para a tomada de decisões. Exemplo: A informação de que os preços da madeira de construção irão cair, podem não ser relevante para uma fábrica de chips de computador.
Simples: A informação deve ser simples, não deve ser exageradamente complexa. A informação detalhada e sofisticada pode não ser necessária. Na realidade, a informação em excesso pode causar sobrecarga da informação, quando um tomador de decisões tem informação demais e não consegue determinar o que é realmente importante.
Em tempo: A informação em tempo é necessária quando necessário. Exemplo: Saber as condições do tempo da semana passada não ajudará a decidir qual agasalho vestir hoje.
Verificável: Finalmente, a informação deve ser verificável. Isto significa que pode-se checá-la para saber se está correto, talvez checando várias fontes da mesma informação.

Dados x Informação

Dados são os fatos em sua forma primária, como por exemplo o nome de um empregado e o número de horas trabalhadas em uma semana, números de peças no estoque . Há vários tipos de dados que podem ser usados para representarem fatos. Quando estes fatos estão organizados ou arranjados de uma maneira significativa, eles se tornam em uma informação.

Informação é um conjunto de fatos organizados de tal forma que adquirem valor adicional além de valor do fato em si. Por exemplo, um certo gerente pode achar que o conhecimento do total de vendas mensais é mais adequado ao seu propósito (tem mais valor) do que as vendas de cada representante de vendas individualmente.

Os dados representam as coisas do mundo real, apenas fatos primários, tem pouco valor além de si mesmos.

A informação é criada definindo-se e organizando as relações entre os dados. A definição de diferentes relações resulta em diferentes informações.

A transformação de dados em informação é um processo, ou uma série de tarefas logicamente relacionadas, executadas para atingir um resultado definido. O processo de definição de relações entre dados requer conhecimento. Conhecimento é o corpo ou as regras, diretrizes e procedimentos usados para selecionar, organizar e manipular os dados, para torna-lo úteis para uma tarefa específica. Por exemplo: Parte do conhecimento necessário para a construção de escadas. É a regra segundo a qual as barras de madeiras devem ser colocadas horizontalmente, e as pernas, verticalmente. O ato da seleção os rejeição dos fatos, baseados na sua relevância em relação as tarefas particulares é também um tipo de conhecimento usado no processo de conversão de dados em informação. Assim, a informação pode ser considerada um dado tornado mais útil através da aplicação do conhecimento. O conjunto de dados, regras, procedimentos e relações que devem ser seguidos para se atingir o valor informacional ou o resultado adequado do processo está contido na base do conhecimento.

Em alguns casos, a organização ou o processamento de dados é feita mentalmente ou manualmente.

Em outros casos, é usado um computador. Exemplo: o gerente poderia ter calculado manualmente as somas das vendas de cada representante, ou esta soma poderia ser feita através de um computador. O importante não é tanto a fonte dos dados ou como eles são processados, mas se os resultados são úteis e de valor para um tomador de decisões.

Representação de números binários – Positivo e Negativo

O sistema de representação de números binários com sinal mais utilizado é o sistema de complemento a 2.

Complemento a 1
O complemento a 1 de um número é obtido substituindo-se cada 0 por 1 e cada 1 por 0.
1 -> 0
0 -> 1
1 -> 0
1 -> 0
0 -> 1
1 -> 0

Complemento a 2
O complemento a 2 de um número binário é obtido tornando-se o complemento a 1 do número e adicionando-se 1 na posição do bit de menor significado.

   1 0 1 1 0 1
+ 0 1 0 0 1 0
   ________1

    0 1 0 0 1 1

45₁₀

Complemento a 1 adiciona complemento a 2 do número binário original.
Ex.

A1  0 1 0 0 1 = +9
      1 0 1 1 0
A2  1 0 1 1 1 = -9
A1  0 1 0 0 0
       ______1
A2  0 1 0 0 1 = + 9

Matéria de Quadro - Equivalência e Implicação Lógica

Equivalência lógica.
Definição: Diz que uma proposição é logicamente equivalente ou apenas equivalente a uma outra proposição, se as tabelas verdade destas duas proposições são idênticas para tal utiliza a notação 
Propriedades
A relação de equivalência lógica entre proposições utiliza-se das propriedades reflexiva = P  P

Simétrica    = Se P<-->Q , então
                        Q<--> P

Transitória = Se  P<--> Q   e
                        Q<-->R, Então
                        P<-->R

Exemplificação.:
As Proposições nnP e P são equivalentes, isto pe simbolicamente nnPP  (Regra da Dupla negação)

P	nP	nnP
V	F	V
F	V	F

As proposições ~Pà e P são equivalentes, isto é simbólicamente ~P->P  <-->P (regra de clavius)

P	~P	~PàP
V	F	V
F	V	F

As condicionais P à P^Q e PàQ também são condicionais equivalentes.
PàP^Q

P	Q	P^Q	PàP^Q	PàQ
V	V	V	V	V
V	F	F	F	F
F	V	F	V	V
F	F	F	V	V

Sendo P -> P^Q <--> P->Q (Regra de absorção) 

Tautologia e Equivalência Lógica:
A proposição P é equivalente a proposição Q, isto é:

P <--> Q

Se e somente se a bicondicional: P <--> Q é tautológica.

Se a proposição P e Q são equivalentes, então, tem tabelas idênticas, e por conseguinte o valor lógico da bicondicional for sempre V, isto é, tautológicos.

P^Q -> R < > (P -> (Q->R))

P	Q	R	P^QàR	ßà	(Pà(QàR))
V	V	V	V	V	V
V	V	F	F	V	F
V	F	V	V	V	V
V	F	F	V	V	V
F	V	V	V	V	V
F	V	F	V	V	V
F	F	V	V	V	V
F	F	F	V	V	V

Portanto, as condicionais
P^Q->R E -> (Q->R) são equivalentes sendo representado:

P^Q -> R <--> P -> (Q->R)

Simb.	Representação
~	“não p”
^	“P e Q”
V	“P ou Q”
V	”ou P ou Q”
->	“... se P então Q”
<- ->	“p se e somente se Q ”

Exemplo:

Se beber, não dirija.
     P               Q            àP^~Q

Se dirigir, não beba.
     P             Q              àQ^~P

Implicação Lógica

Definição diz se que uma proposição P implica logicamente uma proposição Q, se Q é verdade todas as vezes que P for verdade. 

Propriedade
A relação de implicação lógica entre proposições utiliza das propriedades:
Reflexivas = D -> P
Transitivas = Se P -> Q e
                    Q -> R, então
                     P -> R

Exemplificação
As tabelas verdade das proposições:

P ^ Q, P v Q, P <--> Q

São:

P	Q	P^Q	PvQ	PßàQ
V	V	V	V	V
V	F	F	V	F
F	V	F	V	F
F	F	F	F	V

A proposição P^Q é verdadeira somente na linha 1, e nesta linha, as proposições PvQ e PßàQ, também são verdadeiras, logo a primeira proposição implica cada uma das outras duas proposições

P^Q -> PvQ e P^Q -> P <--> Q

A mesma tabela também demonstra as importantes regras de inferência.

(Adição) P -> PvQ e Q -> PvQ
(Simplificação) P^Q -> P e P^Q -> Q

A tabela verdade da proposição (PvQ) ^ ~ P é:

P	Q	PvQ	~P	(PvQ)^~P
V	V	V	F	F
V	F	V	F	F
F	V	V	V	V
F	F	F	V	F

Esta proposição é verdadeira somente na linha 3, e nesta linha, a proposição Q também é verdadeira logo:

(PvQ)^~P -> Q

(Regra do Silogismo disjuntivo)

A tabela verdade das proposições:

(P->Q)^~Q e ~P

P	Q	PàQ	~Q	((PàQ)^~Q)	~P
V	V	V	F	F	F
V	F	F	V	F	F
F	V	V	F	F	V
F	F	V	V	V	V

                        (PàQ)^~Q Þ ~P

(Regra Modos Tollens)
A Mesma tabela demonstra que ~P implica P à Q, isto é:
~P -> P -> Q

Tautologia e Implicação Lógica

A proposição P implica Q, isto é:

P -> Q 

Se e somente se a condicional
P -> Q é tautológica

A condicional P^~P->Q

P	Q	~P	P^~P	P^~PàQ
V	V	F	F	V
V	F	F	F	V
F	V	V	F	V
F	F	V	F	V

Logo, subsiste a implicação lógica P^~P -> Q