Baixado 17 vezes
![Modelo conceitual fisico_logico_er[1]](https://cdn.slidesharecdn.com/ss_thumbnails/modeloconceitualfisicologicoer1-131027120008-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Modelacao de dados
- 1. Análise de Sistemas Modelação de Dados Diagramas de Entidades Relacionamentos Álvaro Rocha amrocha@ufp.pt http://www.ufp.pt/~amrocha Universidade Fernando Pessoa Outubro de 2004 (Baseado em George Marakas, 2001)
- 2. Tópicos Simbologia deDiagramas de Entidades Relacionamentos (DERs) Tipos de Relacionamentos Associações Modelos de Dados Normalização de Dados
- 3. Símbologia básica deDERs Entidade Relacionamento Atributo Atributo multivalor Entidade Associação
- 4. Relacionamentos típicos são comprados por PRODUTOS CLIENTES fornecem FORNECEDORES PRODUTOS contêm ENCOMENDAS PRODUTOS são feitas por ENCOMENDAS CLIENTES estão associados a EMPREGADOS ESCRITÓRIOS são vendidos em PRODUTOS LOJAS
- 5. Complexidade de Relacionamentos (a) Cada EMPREGADO tem de estar associado a um e um só ESCRITÓRIO. associado a EMPREGADO EMPREGADO ESCRITÓRIO ESCRITÓRIO associado a Cada ESCRITÓRIO pode estar associado a zero ou um só EMPREGADO. (b) Cada EMPREGADO tem de estar associado a um e um só associado a DEPARTAMENTO. EMPREGADO EMPREGADO DEPARTAMENTO DEPARTAMENTO a cargo de Cada DEPARTAMENTO pode estar a cargo de zero, um ou mais EMPREGADOS. (c) Cada ESTUDANTE pode estar registado em zero, um ou vários CURSOS. registado para ESTUDANTE ESTUDANTE CURSO CURSO ter Cada CURSO pode ter zero, um ou vários ESTUDANTES.
- 6. Relacionamentos Unários PESSOA PESSOA casada com é um pré-requisito para gerido por CURSO CURSO EMPREGADO EMPREGADO tem um pré-requisto gere Cada PESSOA pode ser casada com nenhuma ou uma só PESSOA. Cada CURSO pode ter zero, um ou vários pré-requistos de CURSOS. Cada CURSO pode ser um pré-requisito para zero, um ou vários CURSOS. Cada EMPREGADO tem de ser gerido por um e um só EMPREGADO. Cada EMPPREGADO pode gerir zero, um ou vários EMPREGADOS.
- 7. Relacionamentos Binários associado a EMPREGADO EMPREGADO ESCRITÓRIO ESCRITÓRIO associado a matriculado em curso ESTUDANTE ESTUDANTE CURSO CURSO frequentado por faz CLIENTE CLIENTE ENCOMENDA ENCOMENDA feita por Cada EMPREGADO tem de estar associado a um e um só ESCRITÓRIO. Cada ESCRITÓRIO pode estar associado a zero ou um só EMPREGADO. Cada ESTUDANTE pode estar matriculado em zero, um ou vários CURSOS. Cada CURSO pode ser frequentado por zero, um ou vários ESTUDANTES. Cada CLIENTE pode fazer zero, uma ou várias ENCOMENDAS. Cada ENCOMENDA tem de ser feita por um e um só CLIENTE.
- 8. Relacionamentos Ternários ESTUDANTE ESTUDANTE PROFESSOR PROFESSOR DISCIPLINA DISCIPLINA Cada ESTUDANTE tem de frequentar uma ou várias DISCIPLINAs e estar associado a um ou mais PROFESSORes. Cada PROFESSOR tem de estar associado a um ou vários ESTUDANTEs e ser responsável por uma ou várias DISCIPLINAs. Cada DISCPLINA tem de ser frequentada por um ou vários ESTUDANTEs e ser da responsabilidade de um ou vários PROFESSORes.
- 9. Entidades Associativas (a) faz reserva de PASSAGEIRO PASSAGEIRO VÔO VÔO é reservado por (b) PASSAGEIRO PASSAGEIRO VÔO VÔO RESERVA RESERVA
- 10. Identificar Entidades eRelacionamentos Questões Descrição Determinar as Entidades do Sistema Identificar as pessoas, unidades de negócio, coisas, lugares, eventos, materiais, ou outros elementos associadas com, ou que interagem com o sistema e sobre os quais os dados têm de ser mantidos. Identificar Atributos das Entidades Identificar as características associadas a cada entidade. Determinar Chaves das Entidades Identificar a característica principal de cada entidade que distingue unicamente uma instância dessa entidade a partir de todas as outras instâncias dessa mesma entidade. Determinar Relacionamentos Identificar os vários eventos, transacções ou outras actividades que implicam uma associação entre entidades. Determinar a Cardinalidade Identificar as circunstâncias sob as quais cada relacionamento pode ocorrer. Isto requer uma investigação das várias formas de operar do negócio/sistema e dos seus contrangimentos.
- 11. Seleccionar uma ChavePrimária Critérios para Selecção Descrição Escolher uma chave candidata que provavelmente não mude o seu valor ao longo do tempo. Estabilidade EXEMPLO: INSTÁVEL ESTÁVEL NAME+ADDRESS EMPLOYEE_ID Escolher uma chave candidata com garantia de que nunca terá valores nulos. Não-Nulos EXEMPLO=: PODE SER NULO NAO-NULO NÚMERO DE TELEFONE N-CONTRIBUINTE Plausível. É preferível ter atributos singulares a atributos múltiplos não exequíveis e não Simplicidade fiáveis. EXEMPLO: ATRIBUTO MÚLTIPLO UM SÓ ATRIBUTO ITEM_NO+COLOR ITEM_CODE
- 12. A Três FormasNormais Forma Normal Descrição Primeira Forma Uma relação está na 1FN se contém elementos de dados não repetidos. Normal (1FN) Segunda Forma Uma relação está na 2FN se está na 1FN e todos os atributos não Normal (2FN) pertencentes a qualquer chave candidata dependem da totalidade da chave e não apenas de parte dela. Terceira Forma Uma relação está na 3FN se está na 2FN e não existem dependências Normal (3FN) funcionais entre os atributos não-chave (dependências transitivas). Ou seja, cada atributo deve depender apenas da chave primária da relação.
- 13. Primeira Forma Normal (a) (b) ORDER ORDER ORDER NUMBER ORDER NUMBER ORDER DATE ORDER DATE CUSTOMER NUMBER CUSTOMER NUMBER CUSTOMER NAME CUSTOMER NAME CUSTOMER STREET CUSTOMER STREET CUSTOMER CITY CUSTOMER CITY CUSTOMER STATE CUSTOMER STATE CUSTOMER ZIPCODE CUSTOMER ZIPCODE CUSTOMER PHONE CUSTOMER PHONE ORDERED PRODUCT (repeats 1 – n times) ORDER SUBTOTAL PRODUCT ID SALES TAX QUANTITY SHIPPING DESCRIPTION ORDER TOTAL UNIT PRICE EXTENDED PRICE ORDERED PRODUCT ORDER SUBTOTAL PRODUCT ID + ORDER NUMBER SALES TAX QUANTITY SHIPPING DESCRIPTION ORDER TOTAL UNIT PRICE EXTENDED PRICE
- 14. Segunda Forma Normal (a) (b) ORDER ORDER ORDER NUMBER ORDER NUMBER ORDER DATE ORDER DATE CUSTOMER NUMBER CUSTOMER NUMBER CUSTOMER NAME CUSTOMER NAME CUSTOMER STREET CUSTOMER STREET CUSTOMER CITY CUSTOMER CITY CUSTOMER STATE CUSTOMER STATE CUSTOMER ZIPCODE CUSTOMER ZIPCODE CUSTOMER PHONE CUSTOMER PHONE ORDER SUBTOTAL ORDER SUBTOTAL SALES TAX SALES TAX SHIPPING SHIPPING ORDER TOTAL ORDER TOTAL ORDERED PRODUCT ORDERED PRODUCT PRODUCT ID + ORDER NUMBER PRODUCT ID + ORDER NUMBER QUANTITY QUANTITY DESCRIPTION UNIT PRICE UNIT PRICE EXTENDED PRICE EXTENDED PRICE PRODUCT PRODUCT ID DESCRIPTION
- 15. Terceira Forma Normal (a) (b) ORDER ORDER ORDER NUMBER ORDER NUMBER ORDER DATE ORDER DATE CUSTOMER NUMBER CUSTOMER NUMBER CUSTOMER NAME ORDER SUBTOTAL CUSTOMER STREET SALES TAX CUSTOMER CITY SHIPPING CUSTOMER STATE ORDER TOTAL CUSTOMER ZIPCODE CUSTOMER PHONE ORDER SUBTOTAL SALES TAX ORDERED PRODUCT SHIPPING PRODUCT ID + ORDER NUMBER ORDER TOTAL QUANTITY UNIT PRICE ORDERED PRODUCT PRODUCT ID + ORDER NUMBER QUANTITY UNIT PRICE PRODUCT EXTENDED PRICE PRODUCT ID DESCRIPTION PRODUCT PRODUCT ID DESCRIPTION CUSTOMER CUSTOMER NUMBER CUSTOMER NAME CUSTOMER STREET CUSTOMER CITY CUSTOMER STATE CUSTOMER ZIPCODE CUSTOMER PHONE
- 16. Desnormalização (a) (b) ORDER ORDER ORDER NUMBER ORDER NUMBER ORDER DATE ORDER DATE CUSTOMER NUMBER CUSTOMER NUMBER ORDER SUBTOTAL ORDER SUBTOTAL SALES TAX SALES TAX SHIPPING SHIPPING ORDER TOTAL ORDER TOTAL ORDERED PRODUCT ORDERED PRODUCT PRODUCT ID + ORDER NUMBER PRODUCT ID + ORDER NUMBER QUANTITY QUANTITY UNIT PRICE UNIT PRICE MTD SALES MONTH ID MONTHLY SALES
- 17. DER Completamente Normalizado Order Order Customer Customer Sales Tax Sales Tax Product ID ++ Order Product ID Order Quantity Quantity Unit Price Unit Price Number Number Number Number Number Number Order Date Order Date ORDER ORDER ORDERED ORDERED PRODUCT PRODUCT Order Order Subtotal Subtotal Shipping Shipping Order Total Order Total Customer Customer CUSTOMER CUSTOMER Customer Customer PRODUCT PRODUCT Number Number Phone Phone Customer Customer Customer Customer Customer Customer Name City Zipcode Product ID Product ID Description Description Name City Zipcode Customer Customer Customer Customer Street Street State State
- 18. Características de umBom Modelo de Dados Característica Descrição Um bom modelo de dados deve ter uma representação gráfica correcta, quer das entidades quer Gráfica dos seus relacionamentos Um bom modelo deve ser rigorso na identificação de todas as entidades e seus relacionamentos Rigoroso bem como na identificação e especificação dos atributos associados a cada entidade. Um bom modelo deve ser decomponível de modo que o nível de detalhe de cada entidade e Decomponível atributos associados possam ser analisados a vários níveis de detalhe e agregação. Foco Um bom modelo de dados deve focar-se apenas nos dados associados a um sistema particular e dentro da fronteira desse mesmo sistema (domínio do discurso). Um bom modelo de dados mostrará redundância mínima no que respeita a entidades, dados e Minimizar Redundância relacionamentos. Os dados actuais e a estrutura física da base de dados devem ser discernidos a partir do modelo Transparência de dados. Um bom modelo de dados deve representar o que se passa no domínio do discurso e a sua Facilidade de Leitura “leitura” ser intuitiva e fácil de seguir. Predizer o Sistema Final Um bom modelo de dados deve ser uma predição correcta do sistema físico a implementar.
- 19. Tarefa extra-aula Leiturada Sebenta “Concepção e Desenvolvimento de Bases de Dados”: http://www2.ufp.pt/~amrocha/as0405