SOLU��O

================================================================================

Mais de uma solu��o pode ser considerada adequada para este exemplo, de acordo com
os coment�rios existentes em cada tabela a seguir.

Tabela TIPO
+----------------------------------+
| CODIGO (PK) | TIPO |
|-------------+--------------------|
| 1 | Banco de dados |
| 2 | Programa��o |
| 3 | Modelagem de dados |
+----------------------------------+
A tabela TIPO foi criada separadamente pois um mesmo tipo de curso poder� ser
utilizado em dezenas de cursos. Para poupar recursos de armazenamento na tabela
CURSO � pois armazenar um n�mero (campo CODIGO) ocupa menos espa�o do que armazenar
textos (campo TIPO) - e tamb�m para disponibilizar os tipos de cursos sem depender
do cadastro de outros cursos, esta informa��o deve ser gerenciada por esta tabela.

Tabela INSTRUTOR
+----------------------------------------+
| CODIGO (PK) | INSTRUTOR | TELEFONE |
|-------------+--------------+-----------|
| 1 | Andr� Milani | 1111-1111 |
| 2 | Carlos Tosin | 1212-1212 |
+----------------------------------------+
A tabela INSTRUTOR foi criada separadamente dos cursos pois um mesmo instrutor pode
ser o respons�vel por um ou mais cursos disponibilizados pela Softblue. Para n�o
haver redund�ncia de dados, gerar economia de espa�o de armazenamento e facilidade
de manuten��o (altera��o de dados do instrutor), estas informa��es devem ser
gerenciadas por esta tabela.

Tabela CURSO
+---------------------------------------------------------------------+
| CODIGO (PK) | CURSO | TIPO (FK) | INSTRUTOR (FK) | VALOR |

|-------------+------------------+-----------+----------------+-------|
| 1 | Java Fundamentos | 2 | 2 | 270 |
| 2 | Java Avan�ado | 2 | 2 | 330 |
| 3 | SQL Completo | 1 | 1 | 170 |
| 4 | Php B�sico | 2 | 1 | 270 |
+---------------------------------------------------------------------+
A tabela CURSO � criada com as colunas TIPO e INSTRUTOR como chaves estrangeiras
(FK) pois representam o c�digo dos registros das outras tabelas as quais fazem
refer�ncia. Desta forma, se o instrutor mudar o seu telefone, ser� necess�rio
alterar apenas na tabela INSTRUTOR, al�m da economia em espa�o de armazenamento por
n�o repetir informa��es.

Tabela ALUNO
+----------------------------------------------------------------------------+
| CODIGO (PK) | ALUNO | ENDERECO | EMAIL |
|-------------+------------+------------------------+------------------------|
| 1 | Jos� | Rua XV de Novembro 72 | jose@softblue.com.br |
| 2 | Wagner | Av. Paulista | wagner@softblue.com.br |
| 3 | Em�lio | Rua Lajes 103, ap: 701 | emilio@softblue.com.br |
+----------------------------------------------------------------------------+
A tabela ALUNO � criada sem nenhuma informa��o sobre as matr�culas j� realizadas
por este aluno, para evitar que seus dados pessoais sejam repetidos em mais de um
registro de matr�cula. Nesta tabela uma possibilidade seria n�o criar a coluna
CODIGO e em seu lugar utilizar a coluna EMAIL como chave prim�ria. Contudo, para
prevenir anomalias de altera��o (pois e-mail � algo que uma pessoa pode mudar e
criar outro, e neste caso seria necess�rio alterar em outras tabelas que fizessem
refer�ncias), bem como para poupar espa�o de armazenamento ao utilizar a chave
prim�ria em outras tabelas, � recomend�vel utilizar c�digos �nicos internos como
chave prim�ria.

Tabela PEDIDO
+----------------------------------------------------+
| CODIGO (PK) | ALUNO (FK) | DATA | HORA |
|-------------+--------------+------------+----------|
| 1 | 2 | 15/04/2010 | 11:23:32 |
| 2 | 2 | 15/04/2010 | 14:36:21 |
| 3 | 3 | 16/04/2010 | 11:17:45 |
+----------------------------------------------------+
A tabela PEDIDO representa o momento em que o aluno realizou o seu pedido, como um
caixa de mercado. Ela apresenta as informa��es do aluno e do momento das
matr�culas, mas como cada aluno pode estar se matriculando em um ou mais cursos no
mesmo pedido, a tabela PEDIDO deve ser referenciada pela tabela PEDIDO_DETALHE,
onde consta cada curso que o aluno est� se matriculando.

Observe que n�o consta o valor total do pedido nesta tabela, pois este valor pode
ser obtido com a soma dos itens que fazem parte deste pedido, gerenciados pela
tabela PEDIDO_DETALHE.

Tabela PEDIDO_DETALHE
+----------------------------------+
| PEDIDO (FK) | CURSO (FK) | VALOR |
|-------------+------------+-------+
| 1 | 1 | 270 |
| 1 | 2 | 330 |
| 2 | 1 | 270 |
| 2 | 2 | 330 |
| 2 | 3 | 170 |
| 3 | 4 | 270 |
+----------------------------------+
A tabela PEDIDO_DETALHE informa quais cursos fazem parte de cada pedido realizado
na Softblue. Observe que a chave prim�ria neste exemplo � formada pelas chaves
estrangeiras PEDIDO e CURSO. Isto ocorre pois em nosso modelo podemos assumir que
n�o � poss�vel comprar dois ou mais cursos iguais em um mesmo pedido.

Observe que existe uma coluna VALOR, que pode parecer redundante com a coluna VALOR
j� existente na tabela CURSO, contudo ela ser� encarregada de armazenar o valor do
curso no momento da matr�cula, j� que futuramente o pre�o na tabela CURSO poder�
ser corrigido devido a novos pre�os praticados pela Softblue.

Como a coluna VALOR desta tabela e a coluna VALOR de CURSOS possivelmente ter�o
valores que poder�o se repetir em v�rios registros, seria poss�vel ainda normalizar
esta coluna em uma tabela chamada PRECO formada por um c�digo (PK) e o valor em
quest�o, e apenas referenciar este c�digo nas tabelas citadas. Contudo, por ser um
campo num�rico e significativamente ocupar menos espa�o que outros campos de texto,
e por outras quest�es de desenvolvimento, este campo n�o ser� normalizado em tabela
pr�pria.

Todas as chaves estrangeiras apresentadas neste exemplo s�o consideradas �ndices.