Final Version - Portfolio 4

/* Em primeiro lugar, deveremos abrir o PostgreSQL e digitar cada sentença ou comando.
A linha seguinte vai criar o banco de dados vazio, denominado "faculdade", onde deverao ser armazenadas as tabelas, ou entidades. */

CREATE DATABASE faculdade ENCODING 'utf8';

/* Em seguida, passamos a criar as tabelas Aluno, Endereco, Curso, Professor, Disciplina e Matricula */

CREATE TABLE  aluno   (id SERIAL PRIMARY KEY NOT NULL,
    nome   VARCHAR(200) NOT NULL,
    fone   VARCHAR(15) NULL,
    cpf   VARCHAR(14) NULL,
    data_nasc   DATE NOT NULL,
    sexo   CHAR(1) NOT NULL
    );
CREATE TABLE endereco  (id   SERIAL PRIMARY KEY NOT NULL,
rua   VARCHAR(100) NOT NULL,
numero   INT NULL,
    bairro   VARCHAR(100) NULL,
    cidade   VARCHAR(100) NOT NULL,
    estado   CHAR(2) NOT NULL,
    outros   CHAR(200) NULL,
    pessoa_id   INT NOT NULL
  );
CREATE TABLE  curso   (id   SERIAL PRIMARY KEY NOT NULL,
    nome   VARCHAR(200) NOT NULL,
    semestre   VARCHAR(6) NOT NULL
    );
CREATE TABLE professor  (id   SERIAL PRIMARY KEY NOT NULL,
    nome   VARCHAR(200) NOT NULL,
    graduacao   VARCHAR(100) NOT NULL,
    fone   VARCHAR(15) NULL
    );
CREATE TABLE disciplina (id   SERIAL PRIMARY KEY NOT NULL,
    nome   VARCHAR(200) NOT NULL,
    professor_id INT NOT NULL,
    curso_id   INT NOT NULL
  );
CREATE TABLE matricula  (id   SERIAL PRIMARY KEY NOT NULL,
    aluno_id   INT NOT NULL,
    curso_id   INT NOT NULL,
    data_matricula DATE NOT NULL
    );

/* Estabeleceremos a partir de agora os relacionamentos, conforme sequencia abaixo.
Na tabela endereco, a chave estrangeira pessoa_id faz referencia a chave primaria id na tabela aluno.
Na tabela disciplina, a chave estrangeira professor_id faz referencia a chave primaria id na tabela professor.
Na tabela disciplina, a chave estrangeira curso_id faz referencia a chave primaria id na tabela curso.
Na tabela matricula, a chave estrangeira aluno_id faz referencia a chave primaria id na tabela aluno.
Na tabela matricula, a chave estrangeira curso_id faz referencia a chave primaria id na tabela curso.
*/

ALTER TABLE endereco ADD CONSTRAINT fk_aluno FOREIGN KEY(pessoa_id) REFERENCES aluno(id) ON DELETE RESTRICT;
ALTER TABLE disciplina ADD CONSTRAINT fk_professor FOREIGN KEY(professor_id) REFERENCES professor(id) ON DELETE RESTRICT;
ALTER TABLE disciplina ADD CONSTRAINT fk_curso FOREIGN KEY(curso_id) REFERENCES curso(id) ON DELETE RESTRICT;
ALTER TABLE matricula ADD CONSTRAINT fk_aluno FOREIGN KEY(aluno_id) REFERENCES aluno(id) ON DELETE RESTRICT;
ALTER TABLE matricula ADD CONSTRAINT fk_curso FOREIGN KEY(curso_id) REFERENCES curso(id) ON DELETE RESTRICT;

/* Agora povoando cada tabela com quatro dados.
Adicionando primeiramente na tabela aluno */

INSERT INTO  aluno VALUES (1,
    'JOYCE VIEIRA',
    '(88) 99624-0845',
    '123.456.789-01',
    '1999-02-28',
    'F'
    );
INSERT INTO  aluno VALUES (2,
    'ELIAS SANTANA',
    '(88) 99902-9575',
    '123.456.789-02',
    '1995-02-27',
    'M'
    );
INSERT INTO  aluno VALUES (3,
    'ADAIL SILVA',
    '(88) 99467-1677',
    '123.456.789-03',
    '1994-02-26',
    'M'
    );
INSERT INTO  aluno VALUES (4,
    'LUCIVALDO SILVA',
    '(85) 99945-6584',
    '123.456.789-04',
    '1974-02-25',
    'M'
    );

/* Na tabela endereco */

INSERT INTO endereco VALUES  (1,
    'RUA MENINO JESUS DE PRAGA',
    200,
    'CIDADE PEDRO MENDES CARNEIRO',
    'SOBRAL',
    'CE',
    'Sem ressalvas',
    2
    );
INSERT INTO  endereco VALUES  (2,
    'RUA C',
    500,
    'JUREMA',
    'CAUCAIA',
    'CE',
    'Mora bem distante do CED',
    4
    );
INSERT INTO endereco VALUES  (3,
    'RUA DR. PAULO SANFORD',
    1350,
    'ALTO DA EXPECTATIVA',
    'SOBRAL',
    'CE',
    'Sem ressalvas',
    3
    );
INSERT INTO  endereco VALUES  (4,
    'TRAVESSA VICENTE ANDRE',
    30,
    'NOSSA SENHORA DE FATIMA',
    'MASSAPE',
    'CE',
    'Mora em outro municipio diverso do CED',
    1
    );

/* Na tabela curso */

INSERT INTO curso VALUES  (1,
    'CURSO DE BANCO DE DADOS DO CED',
    '2015/2'
    );
INSERT INTO curso VALUES  (2,
    'ANDROID DAS MAIS DIVERSAS FORMAS E SABORES',
    '2015/2'
    );
INSERT INTO curso VALUES  (3,
    'CRIANDO CONSULTAS SQL EM BANCO DE DADOS USANDO POSTGRESQL',
    '2014/1'
    );
INSERT INTO curso VALUES  (4,
    'INFORMATICA BASICA USANDO WINDOWS 7 E WORD 2013',
    '2015/1'
    );

/* Na tabela professor */

INSERT INTO professor VALUES  (1,
    'LIVIA SOUSA',
    'TECNOLOGIA DA INFORMACAO',
    '(88) 99934-5254'
    );
INSERT INTO professor VALUES  (2,
    'FRANCISCO ANTONIO BRITO',
    'ENGENHARIA DE PRODUCAO',
    '(88) 99625-9141'
    );
INSERT INTO professor VALUES  (3,
    'LINCOLN FREIRE AGUIAR',
    'ENGENHARIA CIVIL',
    '(88) 99356-3426'
    );
INSERT INTO  professor VALUES  (4,
    'MARCONI PAULINO',
    'COMPUTACAO',
    '(85) 98925-7688'
    );

/* Na tabela disciplina */

INSERT INTO  disciplina VALUES  (1,
    'CURSO AVANCADO DE ALGEBRA E REGRAS LOGARITMICAS',
    2,
    3
    );
INSERT INTO  disciplina VALUES  (2,
    'INFORMATICA AVANCADA',
    1,
    1
    );
INSERT INTO  disciplina VALUES  (3,
    'BANCO DE DADOS',
    3,
    4
    );

INSERT INTO  disciplina VALUES (4,
    'TRIGONOMETRIA BASICA',
    4,
    2
    );

/* Na tabela matricula */  

INSERT INTO  matricula VALUES  (1,
    2,
    1,
    '2015-11-19'
    );
INSERT INTO  matricula VALUES  (2,
    3,
    4,
    '2015-10-29'
    );
INSERT INTO  matricula VALUES  (3,
    4,
    2,
    '2015-05-30'
    );
INSERT INTO  matricula VALUES  (4,
    1,
    3,
    '2015-11-19'
    );

/* Realizando consultas, conforme segue.
- Na tabela aluno, liste todos os registros onde id for igual a 2;
- Na tabela professor, liste todos os registros cujo id for 3;
- Na tabela matricula, liste todos os registros onde aluno_id (chave estrangeira) for 4;
- Na tabela curso, liste todos os registros onde semestre seja 2015/2.
*/

SELECT * FROM aluno WHERE id = 2;
SELECT * FROM professor WHERE id = 3;
SELECT * FROM matricula WHERE aluno_id = 4;
SELECT * FROM curso WHERE semestre = '2015/2';

Portfolios 1, 2 3 e 4

Segue pasta .zip contendo os arquivos dos portfólios do curso.

Portfolio 4 -
http://lucivaldosilva.xpg.uol.com.br/portfolio4.zip

Portfolio 3 -
http://lucivaldosilva.xpg.uol.com.br/portfolio3.zip

Portfolio 2 -
http://lucivaldosilva.xpg.uol.com.br/portfolio2.zip

Portfolio 1 -
http://lucivaldosilva.xpg.uol.com.br/portfolio1.zip

Modelo Logico do Portfolio 4

Pessoal, estamos continuando com a construção da modelagem do problema proposto em nosso portfolio 4, agora passando para o modelo lógico.

Onde há diferenças fundamentais entre os dois modelos? Relacionamentos e Cardinalidade.
Em que diferem? Os relacionamentos "matricula" e "disciplina" (verbos) agora são nominalmente tabelas (matrícula e disciplina), tais como as entidades (substantivos). Com a mudança, a cardinalidade que operava entre as entidades também muda, pois passamos a obedecer a cardinalidade referente aos relacionamentos, que agora também são tabelas. Passamos à interpretação do modelo lógico como um todo, cujo diagrama se encontra no final desta postagem.

As tabelas aluno, endereço, professor e curso (substantivos), cujos correspondentes no modelo conceitual figuravam como entidades têm cada uma cardinalidade de entrada 1,1 (um para um), enquanto as tabelas matrícula e disciplina têm cardinalidade de entrada 1,n (um para muitos). Por quê? Porque só conseguimos visualizar no lado das tabelas "mestras" (as entidades) apenas uma ocorrência de cada registro (tupla) das respectivas tabelas "servidoras" (os relacionamentos), em cujos registros podem ser encontradas várias ocorrências do mesmo registro constante da tabela "substantiva" correspondente. Por exemplo: Várias ocorrências de um mesmo aluno podem ser encontradas nos registros da tabela matrícula, mas apenas uma ocorrência de matrícula na tabela aluno seria possível, para cada aluno cadastrado ali. Podemos pensar de forma igual ao analisar as demais tabelas.

Em cada tabela já se encontram estipuladas, além das chaves primárias e estrangeiras (caso haja), o tamanho máximo de cada campo ou coluna. Confiram.

Modelo Conceitual do Portfolio 4

Olá, pessoal! Vamos tratar hoje do modelo conceitual das entidades de nosso portfolio 4.

* Em nosso modelo conceitual, a tabela endereco, por ser um desmembramento da tabela aluno, será considerada como uma especialização não-exclusiva com criação de entidade.

* As tabelas matricula e disciplina na verdade são relacionamentos. Por quê? No caso da matricula é bem notório, pois aluno_id (que é uma das chaves estrangeiras do relacionamento matricula) refere-se a aluno(id), ou seja ao atributo id da entidade aluno. A outra chave estrangeira será curso_id, que refere-se a curso(id), atributo id da entidade curso, pelo mesmo motivo. Perceberam o relacionamento a que se refere matricula? Suas duas chaves estrangeiras referem-se à tabela aluno e curso, respectivamente. No caso do relacionamento disciplina, ocorre algo semelhante: seu atributo professor_id refere-se à tabela/entidade(atributo/campo) que no caso é professor(id), ou seja, ao atributo id da entidade professor. Semelhantemente, seu atributo curso_id refere-se ao atributo id da entidade curso, ou seja a curso(id).

* O que passo a falar de agora em diante é mais um QUESTIONAMENTO do que uma AFIRMAÇÃO, pois ainda não domino muito bem cardinalidade. São apenas minhas impressões sobre as tabelas:
- Já que Aluno se Matricula no Curso, suas relações de cardinalidade poderão ser: um aluno pode se matricular em nenhum ou em apenas um curso (cardinalidade 0,1). Um curso deve aceitar matrícula de um ou de muitos alunos (cardinalidade 1,n).
- Já que Professor Disciplina o Curso, suas relações de cardinalidade serão: um professor deve disciplinar um ou mais cursos (1,n), e um curso deve ser disciplinado por um e somente um professor (1,1).

* Abaixo segue o diagrama do modelo conceitual, já com as cardinalidades indicadas. Cliquem sobre a tabela para visualizar melhor,

Se minhas afirmativas sobre cardinalidade estiverem erradas, por favor, deixem comentário(s) aqui ou no zap, explicitando o porquê do erro. Se estiverem corretas, comentem que sim, estão corretas. Este humilde aprendiz agradece! :)

Portfólio 3

Atividade – Portfólio III
Tabela 1

Tabela 1- Inicialmente exclui se valores que podem se repetir, criando tabelas onde se insere esses valores sem que ocorra sobrecarga, utiliza-se chaves estrangeiras para fazer a ligação com a outra tabela (1ª - FN), em segundo define as chaves primarias onde todos os atributos da tabela dependem essencialmente de todas as chaves primarias e não apenas de parte dela (2ª –FN), e por fim elimina se todas as colunas que dependem de outra, pois elas devem ser acessadas em tempo de execução, para evitar inconsistência, caso os dados sofram alterações. 

Tabela 2

O mesmo procedimento feito na tabela 1 é aplicado à tabela 2, nesse caso é interessante atentar-se que na tabela Concl (Tabela criada para demonstrar da avaliação), depende de varias informações sendo importadas de outras tabelas através de chaves estrangeiras que também são chaves primarias.

Links para estudo

Normalização com a Profa. Lucélia:
http://professoralucelia.com.br/bd/SlidesNormalizacao.pdf

Normalização com o Prof. Luiz Vivacqua:
http://files.vivacquabd.webnode.com.br/200000046-5949659c69/Exerc%C3%ADcios%20de%20Normaliza%C3%A7%C3%A3o.pdf

Primeiro a Criação da Base de Dados "empresa"
CREATE DATABASE EMPRESA encoding='utf8';

Após a conexão com a mesma no espaço apropriado para execução de comandos SQL (LupaSQL)

Criando as Tabelas "cliente", "produtos" e "fornecedor":

CREATE TABLE cliente(
id SERIAL PRIMARY KEY NOT NULL,
nome VARCHAR(100) NOT NULL,
cpf VARCHAR(20) NOT NULL,
sexo CHAR(1) NOT NULL,
dtNasc DATE NOT NULL,
observacao VARCHAR(100) NULL
);

CREATE TABLE produto(
id SERIAL PRIMARY KEY NOT NULL,
descricao VARCHAR(100) NOT NULL,
dtCompra DATE NOT NULL,
dtValidade DATE NULL
);

CREATE TABLE fornecedor(
id SERIAL PRIMARY KEY NOT NULL,
nome VARCHAR(100) NOT NULL,
cnpj VARCHAR(20) NOT NULL,
dtValidade DATE NULL
);

Criando a Tabela de relacionamento "compra":

CREATE TABLE compra(
id SERIAL PRIMARY KEY NOT NULL,
produto INTEGER NOT NULL,
cliente INTEGER NOT NULL,
CONSTRAINT FK_CLIENTE FOREIGN KEY(cliente) REFERENCES cliente(id) ON DELETE RESTRICT
);

Inserindo dados na tabela "cliente":
INSERT INTO cliente VALUES(1,'AdailSilva',000.000.000-00,'M','1900-01-01','Tianguá-CE');
INSERT INTO cliente VALUES(2,'SeuNomeAgora',999.999.999-99,'F','1900-01-01','Sobral-CE');
INSERT INTO cliente VALUES(3,'João Pedro',000.000.000-00,'M','1900-01-01','Ubajara-CE');

Inserindo dados na tabela "produto":
INSERT INTO produto VALUES(1,'Notebook','2015-11-12','2016-01-01');
INSERT INTO produto VALUES(2,'Desktop','2015-11-12','2016-01-01');
INSERT INTO produto VALUES(3,'Servidor','2014-11-12','2016-12-01');
INSERT INTO produto VALUES(4,'Software SIS','2015-11-12','2016-01-01');

Inserindo dados na tabela "fornecedor":
INSERT INTO fornecedor VALUES(1,'Meu Primeiro Fornecedor','00.000.000/0001-00','2016-01-01');
INSERT INTO fornecedor VALUES(2,'Meu Segundo Fornecedor','00.000.000/0001-00','2016-01-01');
INSERT INTO fornecedor VALUES(3,'Meu Terceiro Fornecedor','00.000.000/0001-00','2016-01-01');

Inserindo dados na tabela de relacionamento "compra":
INSERT INTO compra VALUES(1,2,3); (Minha primeira venda foi do produto 2 para o cliente 3)
INSERT INTO compra VALUES(2,3,1); (Minha segunda venda foi do produto 3 para o cliente 1)

E assim sucessivamente! ;-)

⊂⊃⊂ \('~')/ ➜ AdailSilva☺ ⊃⊂⊃

Normalização.

Normalização é um processo a partir do qual se aplicam regras a todas as tabelas do banco de dados com o objetivo de evitar falhas no projeto, como redundância de dados e mistura de diferentes assuntos numa mesma tabela.

Ao projetar um banco de dados, se temos um modelo de entidades e relacionamentos e a partir dele construirmos o modelo relacional seguindo as regras de transformação corretamente, o modelo relacional resultante estará, provavelmente, normalizado. Mas, nem sempre os modelos que nos deparamos são implementados dessa forma e, quando isso acontece, o suporte ao banco de dados é dificultado.

Em ambos os casos, é necessário aplicar as técnicas de normalização, ou para normalizar (segundo caso citado), ou apenas para validar o esquema criado (primeiro caso citado). Aplicando as regras descritas a seguir, é possível garantir um banco de dados mais íntegro, sem redundâncias e inconsistências.

Existem 3 formas normais mais conhecidas:

• 1FN - 1ª Forma Normal:todos os atributos de uma tabela devem ser atômicos, ou seja, a tabela não deve conter grupos repetidos e nem atributos com mais de um valor. Para deixar nesta forma normal, é preciso identificar a chave primária da tabela, identificar a(s) coluna(s) que tem(êm) dados repetidos e removê-la(s), criar uma nova tabela com a chave primária para armazenar o dado repetido e, por fim, criar uma relação entre a tabela principal e a tabela secundária. Por exemplo, considere a tabela Pessoas a seguir.
  PESSOAS = {ID+ NOME + ENDERECO + TELEFONES}
  Ela contém a chave primária ID e o atributo TELEFONES é um atributo multivalorado e, portanto, a tabela não está na 1FN. Para deixá-la na 1FN, vamos criar uma nova tabela chamada TELEFONES que conterá PESSOA_ID como chave estrangeira de PESSOAS e TELEFONE como o valor multivalorado que será armazenado.
  PESSOAS = { ID + NOME + ENDERECO }
  TELEFONES = { PESSOA_ID + TELEFONE }
• 2FN - 2ª Forma Normal:antes de mais nada, para estar na 2FN é preciso estar na 1FN. Além disso, todos os atributos não chaves da tabela devem depender unicamente da chave primária (não podendo depender apenas de parte dela). Para deixar na segunda forma normal, é preciso identificar as colunas que não são funcionalmente dependentes da chave primária da tabela e, em seguida, remover essa coluna da tabela principal e criar uma nova tabela com esses dados. Por exemplo, considere a tabela ALUNOS_CURSOS a seguir.
  ALUNOS_CURSOS = { ID_ALUNO + ID_CURSO + NOTA + DESCRICAO_CURSO }
  Nessa tabela, o atributo DESCRICAO_CURSO depende apenas da chave primária ID_CURSO. Dessa forma, a tabela não está na 2FN. Para tanto, cria-se uma nova tabela chamada CURSOS que tem como chave primária ID_CURSO e atributo DESCRICAO retirando, assim, o atributo DESCRICAO_CURSO da tabela ALUNOS_CURSOS.
  ALUNOS_CURSOS = {ID_ALUNO + ID_CURSO + NOTA}
  CURSOS = {ID_CURSO + DESCRICAO}
• 3FN - 3ª Forma Normal:para estar na 3FN, é preciso estar na 2FN. Além disso, os atributos não chave de uma tabela devem ser mutuamente independentes e dependentes unicamente e exclusivamente da chave primária (um atributo B é funcionalmente dependente de A se, e somente se, para cada valor de A só existe um valor de B). Para atingir essa forma normal, é preciso identificar as colunas que são funcionalmente dependentes das outras colunas não chave e extraí-las para outra tabela. Considere, como exemplo, a tabela FUNCIONARIOS a seguir.
  FUNCIONARIOS = { ID + NOME + ID_CARGO + DESCRICAO_CARGO }
  O atributo DESCRICAO_CARGO depende exclusivamente de ID_CARGO (atributo não chave) e, portanto, deve-se criar uma nova tabela com esses atributos. Dessa forma, ficamos com as seguintes tabelas:
  FUNCIONARIOS = { ID + NOME + ID_CARGO }
  CARGOS = { ID_CARGO + DESCRICAO }

Como exercício, normalize a tabela EMPREGADOS a seguir.

Para mais detalhes sobre a normalização, veja os links da Fonte desta matéria.

Fontes:

[1] http://www.slidefinder.net/b/banco_dados_unidade_projeto_relacional/30886481. Último acesso em 15/05/2011.

[2] http://www.luis.blog.br/normalizacao-de-dados-e-as-formas-normais.aspx. Último acesso em 15/05/2011.

[3] http://pt.wikipedia.org/wiki/Normaliza%C3%A7%C3%A3o_em_banco_de_dados. Último acesso em 15/05/2011.

[4] http://support.microsoft.com/kb/283878/pt-br. Último acesso em 15/05/2011.

[5] http://blogdati.com.br/?p=43. Último acesso em 15/05/2011.

Portfolio do Elias

Centro de Educação a Distância do Ceará

Curso de Introdução a Banco de Dados

Professor: Alexandre Rocha

Monitores: Lívia Sousa/Dougllas Frota

Atividade – Portfólio II

Ø  A partir dos conteúdos das aulas 1, 2 e 3, responda o seguinte questionário. Você poderá utilizar como fonte de pesquisa as aulas do curso ou outros materiais externos. O arquivo a ser enviado deve conter seu nome completo e a resposta relacionada à respectiva questão. Bom trabalho!

1.       Qual a importância dos bancos de dados para os Sistemas de Informação?

Inicialmente, banco de dados é um conjunto de informações relacionadas entre si, organizadas de uma forma bastante prática para que o usuário obtenha as informações facilmente.

Sistema de Informação é o gerenciamento do fluxo de dados na organização, onde tem por objetivo ajudar no planejamento, implementação e controle dos processos.

A importância de um banco de dados no sistema de informação em uma empresa especificamente é uma poderosa ferramenta, pois um banco de dados bem estruturado e integrado, os gestores são capazes de tomar decisões mais adequadas.

2.       O que é um Banco de Dados? Cite dois exemplos de sistemas que você acredita que utiliza banco de dados.

“Bancos de dados são coleções de dados interligados entre si e organizados para fornecer informações.” Exemplos de Banco de Dados que tenho conhecimento, são os bancários, onde funciona o cadastro de clientes que necessitam de grande atenção para o não vazamento de informações. A empresa de Calçados Grendene S/A que possui cadastrado em seu banco de dados cadastro de funcionários, clientes e produtos, e podemos ver também a execução do banco de dados em nosso dia a dia, no comercio e em hospitais.

3.       Qual o objetivo da modelagem de um banco de dados?

Modelar significa criar um modelo que explique as características de funcionamento e comportamento de um software a partir do qual ele será criado, facilitando seu entendimento e seu projeto, através das características principais que evitarão erros de programação, projeto e funcionamento. É uma parte importante do desenho de um sistema de informação.

Os modelos de dados são ferramentas que permitem demonstrar como serão construídas as estruturas de dados que darão suporte aos processos de negócio, como esses dados estarão organizados e quais os relacionamentos que pretendemos estabelecer entre eles. A abordagem que se dispensa ao assunto normalmente atende a três perspectivas:

Modelagem Conceitual: é usada como representação de alto nível e considera exclusivamente o ponto de vista do usuário criador dos dados;

Modelagem Lógica: agrega mais alguns detalhes de implementação.

Modelagem Física: demonstra como os dados são fisicamente armazenados.

4.       Quais as etapas de um Projeto de Desenvolvimento de um Sistema de Banco de Dados? O que é feito em cada uma dessas etapas?

5.       Para que serve o Diagrama Entidade Relacionamento? 

Em engenharia de software, um modelo entidade relacionamento (modelo ER) é um modelo de dados para descrever os dados ou aspectos de informação de um domínio de negócio ou seus requerimentos de processo, de uma maneira abstrata que em última análise se presta a ser implementada em um banco de dados, como um banco de dados relacional. Os principais componentes dos Modelos Entidades Relacionamento (MER) são as entidades (coisas, objetos) suas relações e armazenamento em bancos de dados.

A 'MER' foi desenvolvida por Peter Chen e publicada em um artigo de 1976. Entretanto, variantes da ideia existiram anteriormente e, posteriormente, foram imaginadas como entidades de dados de supertipo e subtipo e relacionamentos de uniformização.

6.       Defina o que é entidade e dê pelo menos três exemplos de entidades.

Conjunto de objetos da realidade modelada, sobre os quais deseja-se manter informações no banco de dados. Podemos ter como exemplo de entidade: Peça, fornecedor e produto.

7.       Defina atributo e cite 04 atributos para cada entidade que você citou na questão anterior.

Dado que é associado a cada ocorrência de uma entidade ou de um relacionamento. Podemos citar quantidade, descrição, preço e modelo como atributo de peça, e nome, endereço, telefone e CNPJ para fornecedor, e fechando código, quantidade, descrição e preço para produto.

8.       Explique o que é chave primária e para que ela serve. Apresente 3 exemplos de atributos que poderiam ser chave primária e explique o porque.

Chaves primárias (em inglês, Primary keys ou "PK"), sob o ponto de vista de um banco de dados relacional, referem-se aos conjuntos de um ou mais campos, cujos valores, considerando a combinação de valores em caso de mais de uma chave primária, nunca se repetem na mesma tabela e, desta forma, podem ser usadas como um índice de referência para criar relacionamentos com as demais tabela do banco de dados (daí vem o nome banco de dados relacional). No caso do Professor, o atributo que seria classificado de chave primária seria a matricula, por não poder ser repetido e possuir o menor conjunto de caracteres, o que torna o banco de dados mais enxuto. Usando esta mesma razão, temos o aluno, que também pode utilizar a matricula como chave primária e um médico teria o CRM como chave primária.

9.       Uma chave primária pode assumir valor nulo? Explique sua resposta.

O campo que é chave primária tem que ter um valor inserido. Não pode ser nulo, nem assumir o valor zero.

10.   O que é cardinalidade? Qual a diferença entre cardinalidade mínima e máxima?

Cardinalidade é um dos princípios fundamentais sobre o relacionamento de um banco de dados relacional. Nela são definidos o graus de relação entre duas entidades ou tabelas.No modelo relacional, podemos ter os seguintes níveis de relacionamento: 1:N, N:N, 1:1.

Cardinalidade mínima: Indica o número mínimo de ocorrências de uma entidade associada à outra ocorrência da outra entidade relacionada.

Cardinalidade máxima: Indica o número máximo de ocorrências de uma entidade associada à outra ocorrência de outra entidade relacionada. É representado por 1 (uma ocorrência) ou n (várias ocorrências).

11.   Desenhe o diagrama das situações abaixo, definindo no mínimo 3 atributos para cada entidade, a chave primária e a cardinalidade do relacionamento.

a) Uma universidade tem muitos estudantes e um estudante pode se dedicar a no máximo uma universidade.

b) Uma aeronave pode ter muitos passageiros, mas um passageiro só pode estar em um vôo de cada vez.

c) Um paciente pode ter muitos médicos e um médico muitos pacientes.

d) Uma nação possui vários estados, e um estado, muitas cidades. Um estado só poderá estar vinculado a uma nação e uma cidade só poderá estar vinculado a um estado.

12.   Dado osDER’s abaixo, aplique a cardinalidade para cada um dos relacionamentos,coloque os atributos para cada entidade e marque as chaves primárias para cada entidade.