Modelo Relacional Wendel Melo

Transcrição

1 Wendel Melo Faculdade de Computação Universidade Federal de Uberlândia Banco de Dados I

2 2 Proposto por Ted Codd em 1970; Se tornou padrão nos principais SGBD s de uso geral devido a sua simplicidade e embasamento matemático; O modelo relacional abre mão de algumas funcionalidades presentes em outros tipos de modelo, como o Entidade Relacionamento. Esse foco na simplicidade permite implementações eficientes para a manipulação dos dados, o que contribuiu fortemente para o sucesso dos SGBD s relacionais.

3 3 - Limitações Em nome da eficiência na manipulação dos dados, as seguintes limitações são impostas no modelo relacional: Todo atributo deve ser monovalorado; Atributos multivalorados não são permitidos. Apenas entidades (relações) podem possuir atributos. Não há atributos de relacionamento; Cada relacionamento envolve, no máximo, duas entidades (relações) distintas;

4 4 - Limitações Em nome da eficiência na manipulação dos dados, as seguintes limitações são impostas no modelo relacional: Apenas relacionamentos do tipo um para um ou um para muitos são permitidos; Assim, relacionamentos do tipo muitos para muitos precisam ser decompostos em dois relacionamentos um para muitos com uma entidade (relação) auxiliar.

5 5 O modelo relacional representa o banco de dados como um conjunto de relações. Podemos encarar o termo relação como sendo sinônimo de tabela. Ex: a relação de alunos do curso de BD (a tabela (listagem) de alunos de BD). Assim, o modelo relacional é baseado em tabelas bidimensionais (linha e coluna); Uma relação é a representação de uma entidade do mundo real (um objeto, conceito ou fato), e pode ser encarada como uma tabela.

6 Dada uma tabela associada à uma relação R: As linhas (tuplas) representam instâncias da relação (entidade) sendo modelada; As colunas representam os atributos da relação; Cada célula armazena um valor de atributo para uma instância da relação (entidade); Pessoa nome cpf sexo dt_nasc altura Laura G F 30/03/ Camila C F Fernanda P /01/

7 Pelo fato do modelo ser baseado em tabela bidimensionais, cada célula armazena um valor atômico (que não pode ser subdividido em seu domínio); Assim, não há suporte para atributos multivalorados; Para armazenar 3 telefones de uma pessoa, seria preciso criar 3 atributos distintos, ou uma nova relação apenas para telefones; Pessoa nome cpf sexo dt_nasc altura Laura G F 30/03/ Camila C F Fernanda P /01/

8 Formalmente, cada linha da tabela é chamada de tupla ou n- tupla (lista composta por n valores); Cada componente da tupla pode conter um dado de um determinado tipo sujeito a um domínio de possíveis valores; Um domínio pode receber um nome, um tipo de dado e um formato. Ex: o atributo cpf pode estar em um domínio chamado cpf_brasil com o tipo sequência de 11 dígitos. Pessoa char[200] cpf_brasil {F, M} date float nome cpf sexo dt_nasc altura Laura G F 30/03/ Camila C F Fernanda P /01/

9 Um esquema para descrever uma relação R é indicado por: atributos R(A 1, A 2,, A n ) dom(a i ) representa o domínio do atributo A i ; Pessoa nome cpf sexo dt_nasc altura Laura G F 30/03/ Camila C F Fernanda P /01/

10 Um esquema para descrever uma relação R é indicado por: atributos R(A 1, A 2,, A n ) dom(a i ) representa o domínio do atributo A i ; Para o nosso exemplo, temos: Pessoa(nome, cpf, sexo, dt_nasc, altura) Pessoa nome cpf sexo dt_nasc altura Laura G F 30/03/ Camila C F Fernanda P /01/

11 O(s) atributo(s) sublinhado(s) compõe(m) a chave primária da relação; Pode-se detalhar melhor indicando os tipos dos atributos: Pessoa(nome: char[200], cpf: char[11], sexo: char, dt_nasc: date, altura: float) Pessoa nome cpf sexo dt_nasc altura Laura G F 30/03/ Camila C F Fernanda P /01/

12 Podemos representar relações graficamente: Pessoa nome cpf sexo dt_nasc altura Laura G F 30/03/ Camila C F Fernanda P /01/

13 A definição de uma relação não inclui uma ordem específica para as tuplas (linhas); Assim, as tuplas da tabela Pessoa poderiam ser apresentadas em qualquer ordem, que, ainda assim, o estado corrente da relação seria o mesmo; Pessoa nome cpf sexo dt_nasc altura Laura G F 30/03/ Camila C F Fernanda P /01/

14 14 Exemplo - Construa um modelo de dados relacional que atenda aos seguintes requisitos de um berçário: 1) É necessário manter um cadastro dos pais com nome, RG, sexo, data de nascimento, telefone e endereço; 2) A cada bebê que nasce, são cadastrados nome, data/hora de nascimento, sexo, peso, altura, tipo de parto, pai (quando for conhecido) e mãe; 3) Para cada profissional de saúde, são armazenados nome, RG, CPF, data de nascimento, registro de ordem (se houver) e um dos cargos pré-cadastrados em uma relação de cargos; 4) É preciso cadastrar quais os profissionais envolvidos no nascimento de cada bebê.

15 15 Exemplo - Diagrama construído usando a ferramenta MySQL Workbench.

16 16 Exemplo - Considerações sobre a notação do MySQL Workbench

17 17 Exemplo - A chave indica que o atributo compõe a chave primária da relação.

18 18 Exemplo - Losango cheio indica que o atributo é de preenchimento obrigatório.

19 19 Exemplo - Losango vazado indica que o atributo é de preenchimento não obrigatório.

20 20 Exemplo - Losango ou chave vermelha indica chave estrangeira. Quando a chave estrangeira é parte também da chave primária, é usada a chave. Quando a chave estrangeira não é parte da chave, é usado losango.

21 21 Exemplo - Relacionamento 1:n identificador (chave estrangeira participa da chave primária, preenchimento obrigatório). Dois traços verticais: 1 Um vertical e dois diagonais: n

22 22 Exemplo - Relacionamento 1:n não identificador (chave estrangeira participa da chave primária), preenchimento não obrigatório. A bola ao lado esquerdo indica que o bebê pode ter 0 ou 1 pai. Traço vertical com bola: 0 ou 1 Um vertical e dois diagonais: n

23 23 Exemplo - Relacionamento 1:n não identificador (chave estrangeira não participa da chave primária) com preenchimento obrigatório. Dois traços verticais: 1 Um vertical e dois diagonais: n

24 24 Exemplo - Considerações sobre a modelagem

25 25 Exemplo - O modelo prevê dois genitores para cada bebê (pai e mãe). Por essa razão, há dois relacionamentos entre Genitor e Bebe, com duas chaves estrangeiras em Bebe.

26 26 Exemplo - Cada genitor pode ter vários bebês. Por sua vez, cada bebê só terá um genitor como mãe e um ou zero genitor como pai. Por essa razão, esses relacionamentos são 1:n (um para muitos)

27 27 Exemplo - Observe que a chave primária de Bebe é composta de nome e mãe. Isso porque é possível que vários bebês tenham o mesmo nome. Observe que Bebe é uma entidade fraca, pois por não possuir chave candidata própria, pega carona chave primária de Genitor.

28 28 Exemplo - Cada profissional de saúde deve ter um cargo. Em cada cargo, podemos ter vários profissionais. Por essa razão, esse relacionamento é 1:n.

29 29 Exemplo - Note que a chave estrangeira em Profissional_saude não faz parte da chave primária. Por essa razão, o uso da linha pontilhada.

30 30 Exemplo - Note que cargo não possui uma chave candidata própria. Por essa razão, criamos uma chave primária artificial chamada idcargo.

31 31 Exemplo - Para cada bebê nascer. Podemos ter vários profissionais envolvidos. Por sua vez, cada profissional pode trabalhar no nascimento de vários bebês. Desse modo, temos um relacionamento n:n entre Bebe e Profissional_saude.

32 32 Exemplo - Como o modelo relacional não suporta relacionamentos n:n diretamente, foi necessário criar uma relação auxiliar Profissional_saude_has_Bebe. Em cada linha dessa relação, temos uma par profissional, bebê. Assim, é possível listar todos os profissionais que atuaram com cada bebê.

33 33 Exemplo - Assim, ambos Bebe e Profissional_saude terão relacionamento 1:n com a relação auxiliar Profissional_saude_has_Bebe.

34 34 Exemplo - Podemos representar o esquema modelado da seguinte forma: Genitor(RG, nome, sexo, dt_nasc, telefone, endereco) Bebe(nome, Genitor_mae_RG, Genitor_pai_RG, dthr_nasc, sexo, peso, altura, tipo_parto) Profissional_saude_has_Bebe(Bebe_nome, Bebe_Genitor_mae, Profissional_saude_CPF) Profissional_saude(CPF, RG, nome, dt_nasc, registro, Cargo_idCargo) Cargo(idCargo, nome_cargo, descricao)

35 Bebe nome Profissional _saude Relacionamento n:n na prática Genitor_ mae_rg Genitor _pai_rg dthr_nasc se xo pe so altu ra tipo_pa rto Joãozinho :41 M Normal Mariazinha :26 F Normal Zequinha :57 M 3 51 Normal Joãozinho : Normal CPF RG nome dt_nasc registro Cargo_idCargo Cesar M Cristine S Camila R Viviane Z Profissional_saude _has_bebe Profissional_saude Bebe_nome Bebe_Genitor_mae Joãozinho Joãozinho Mariazinha Mariazinha Mariazinha

36 Bebe nome Profissional _saude Relacionamento n:n na prática Genitor_ mae_rg Genitor _pai_rg dthr_nasc se xo pe so altu ra tipo_pa rto Joãozinho :41 M Normal Mariazinha :26 F Normal Zequinha :57 M 3 51 Normal Joãozinho : Normal CPF RG nome dt_nasc registro Cargo_idCargo Cesar M Cristine S Camila R Viviane Z Profissional_saude _has_bebe Profissional_saude Bebe_nome Bebe_Genitor_mae Joãozinho Joãozinho Mariazinha Mariazinha Mariazinha

37 37 Restrições do Restrição de integridade das instâncias de relações: exige que nenhum valor de chave primária possa estar vazio (NULL), pois isso impediria a identificação de uma instância da relação; Restrição de chave: estabelece que cada instância da relação possui um valor de chave primária diferente de todas as demais que existem, ou já existiram no BD; Restrição de integridade referencial: impõe consistência no relacionamento entre relações, isto é, que cada chave estrangeira em um exemplar de uma relação possua um valor que de fato seja chave primária de alguma instância de outra relação;

38 38 Restrições do Restrição de domínio: especifica que cada valor deve estar no domínio do seu respectivo atributo; Restrição de não-nulidade (NOT NULL): impõe que atributos de uma relação marcados como NOT NULL não podem estar vazios em nenhuma das suas instâncias. As restrições anteriores são especificadas no esquema de BD relacional através da Linguagem de Definição de Dados (DDL); A Linguagem de Consulta Estruturada (SQL) contém instruções que atuam como DDL;

39 39 Restrições do Um esquema de banco de dados é um conjunto de esquemas de relação e um conjunto de restrições de integridade; Se todas as instâncias de relações presentes no BD obedecem a todas as restrições anteriores, dizemos que o BD está em um estado válido. Caso contrário, dizemos que o BD está em um estado inválido;