Modelacao de dados

Análise de Sistemas

Modelação de Dados

Diagramas de Entidades Relacionamentos

Álvaro [email protected]

http://www.ufp.pt/~amrochaUniversidade Fernando Pessoa

Outubro de 2004(Baseado em George Marakas, 2001)

mailto:[email protected]

mailto:[email protected]

http://www.ufp.pt/~amrocha/as0304

http://www.ufp.pt/~amrocha/as0304

Tópicos

Simbologia de Diagramas de Entidades Relacionamentos (DERs)Tipos de RelacionamentosAssociaçõesModelos de DadosNormalização de Dados

Símbologia básica de DERs

Entidade Relacionamento

Atributo Atributo multivalor

EntidadeAssociação

Relacionamentos típicos

são comprados porPRODUTOS CLIENTES

fornecemFORNECEDORES PRODUTOS

contêmENCOMENDAS PRODUTOS

são feitas porENCOMENDAS CLIENTES

estão associados aEMPREGADOS ESCRITÓRIOS

são vendidos emPRODUTOS LOJAS

Complexidade de Relacionamentos

(a)

(b)

(c)

EMPREGADOEMPREGADO ESCRITÓRIOESCRITÓRIO

EMPREGADOEMPREGADO DEPARTAMENTODEPARTAMENTO

ESTUDANTEESTUDANTE CURSOCURSO

Cada EMPREGADO tem de estarassociado a um e um só ESCRITÓRIO.

Cada ESCRITÓRIO pode estar associadoa zero ou um só EMPREGADO.

Cada EMPREGADO tem de estarassociado a um e um sóDEPARTAMENTO.

Cada DEPARTAMENTO pode estar a cargo de zero, um ou maisEMPREGADOS.

Cada ESTUDANTE pode estar registadoem zero, um ou vários CURSOS.

Cada CURSO pode ter zero, um ou váriosESTUDANTES.

associado a

associado a

associado a

a cargo de

registado para

ter

Relacionamentos Unários

PESSOAPESSOA

CURSOCURSO EMPREGADOEMPREGADO

casada com

é um pré-requisito para

tem um pré-requisto

gerido por

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.

Relacionamentos Binários

EMPREGADOEMPREGADO

ESTUDANTEESTUDANTE CURSOCURSO

associado a

associado a

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.

ESCRITÓRIOESCRITÓRIO

CLIENTECLIENTE ENCOMENDAENCOMENDA

matriculado em curso

frequentado por

faz

feita por

Relacionamentos Ternários

ESTUDANTEESTUDANTE

DISCIPLINADISCIPLINA

PROFESSORPROFESSOR

Cada ESTUDANTE tem de frequentar uma ou várias DISCIPLINAs e estar associado a um ou maisPROFESSORes.

Cada PROFESSOR tem de estar associado a um ou vários ESTUDANTEs e ser responsável poruma ou várias DISCIPLINAs.

Cada DISCPLINA tem de ser frequentada por um ou vários ESTUDANTEs e ser da responsabilidadede um ou vários PROFESSORes.

Entidades Associativas

PASSAGEIROPASSAGEIRO

VÔOVÔOPASSAGEIROPASSAGEIRO

VÔOVÔO

RESERVARESERVA

faz reserva de

é reservado por

(a)

(b)

Identificar Entidades e Relacionamentos

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 osquais 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 unicamenteuma instância dessa entidade a partir de todas as outras instâncias dessa mesmaentidade.

Determinar Relacionamentos Identificar os vários eventos, transacções ou outras actividades que implicam umaassociação entre entidades.

Determinar a Cardinalidade Identificar as circunstâncias sob as quais cada relacionamento pode ocorrer. Istorequer uma investigação das várias formas de operar do negócio/sistema e dos seus contrangimentos.

Seleccionar uma Chave Primária

Critérios para Selecção Descrição

EstabilidadeEscolher uma chave candidata que provavelmente não mude o seu valor ao longo do tempo.EXEMPLO: INSTÁVEL ESTÁVEL

NAME+ADDRESS EMPLOYEE_ID

Não-NulosEscolher uma chave candidata com garantia de que nunca terá valores nulos.EXEMPLO=: PODE SER NULO NAO-NULO

NÚMERO DE TELEFONE N-CONTRIBUINTE

SimplicidadePlausível. É preferível ter atributos singulares a atributos múltiplos não exequíveis e não

fiáveis.EXEMPLO: ATRIBUTO MÚLTIPLO UM SÓ ATRIBUTO

ITEM_NO+COLOR ITEM_CODE

A Três Formas Normais

Forma Normal Descrição

Primeira Forma Normal (1FN)

Uma relação está na 1FN se contém elementos de dados não repetidos.

Segunda Forma Normal (2FN)

Uma relação está na 2FN se está na 1FN e todos os atributos nãopertencentes a qualquer chave candidata dependem da totalidade dachave e não apenas de parte dela.

Terceira Forma Normal (3FN)

Uma relação está na 3FN se está na 2FN e não existem dependênciasfuncionais entre os atributos não-chave (dependências transitivas). Ouseja, cada atributo deve depender apenas da chave primária da relação.

Primeira Forma Normal

ORDERORDER NUMBERORDER DATECUSTOMER NUMBERCUSTOMER NAMECUSTOMER STREETCUSTOMER CITYCUSTOMER STATECUSTOMER ZIPCODECUSTOMER PHONEORDERED PRODUCT (repeats 1 – n times)PRODUCT IDQUANTITYDESCRIPTIONUNIT PRICEEXTENDED PRICEORDER SUBTOTALSALES TAXSHIPPINGORDER TOTAL

ORDERORDER NUMBERORDER DATECUSTOMER NUMBERCUSTOMER NAMECUSTOMER STREETCUSTOMER CITYCUSTOMER STATECUSTOMER ZIPCODECUSTOMER PHONEORDER SUBTOTALSALES TAXSHIPPINGORDER TOTAL

ORDERED PRODUCT PRODUCT ID + ORDER NUMBERQUANTITYDESCRIPTIONUNIT PRICEEXTENDED PRICE

(a) (b)

Segunda Forma Normal

ORDERORDER NUMBERORDER DATECUSTOMER NUMBERCUSTOMER NAMECUSTOMER STREETCUSTOMER CITYCUSTOMER STATECUSTOMER ZIPCODECUSTOMER PHONEORDER SUBTOTALSALES TAXSHIPPINGORDER TOTAL

ORDERED PRODUCT PRODUCT ID + ORDER NUMBERQUANTITYDESCRIPTIONUNIT PRICEEXTENDED PRICE

(a) (b)ORDERORDER NUMBERORDER DATECUSTOMER NUMBERCUSTOMER NAMECUSTOMER STREETCUSTOMER CITYCUSTOMER STATECUSTOMER ZIPCODECUSTOMER PHONEORDER SUBTOTALSALES TAXSHIPPINGORDER TOTAL

ORDERED PRODUCT PRODUCT ID + ORDER NUMBERQUANTITYUNIT PRICEEXTENDED PRICE

PRODUCT PRODUCT ID DESCRIPTION

Terceira Forma Normal

(a) (b)ORDERORDER NUMBERORDER DATECUSTOMER NUMBERCUSTOMER NAMECUSTOMER STREETCUSTOMER CITYCUSTOMER STATECUSTOMER ZIPCODECUSTOMER PHONEORDER SUBTOTALSALES TAXSHIPPINGORDER TOTAL

ORDERED PRODUCT PRODUCT ID + ORDER NUMBERQUANTITYUNIT PRICEEXTENDED PRICE


ORDERORDER NUMBERORDER DATECUSTOMER NUMBERORDER SUBTOTALSALES TAXSHIPPINGORDER TOTAL

ORDERED PRODUCT PRODUCT ID + ORDER NUMBERQUANTITYUNIT PRICE


CUSTOMERCUSTOMER NUMBERCUSTOMER NAMECUSTOMER STREETCUSTOMER CITYCUSTOMER STATECUSTOMER ZIPCODECUSTOMER PHONE

Desnormalização

(a) (b)ORDERORDER NUMBERORDER DATECUSTOMER NUMBERORDER SUBTOTALSALES TAXSHIPPINGORDER TOTAL


ORDERORDER NUMBERORDER DATECUSTOMER NUMBERORDER SUBTOTALSALES TAXSHIPPINGORDER TOTAL


MTD SALESMONTH ID MONTHLY SALES

DER Completamente Normalizado

ORDERORDER

PRODUCTPRODUCTCUSTOMERCUSTOMER

ORDERED PRODUCTORDERED PRODUCT

CustomerName

CustomerName

CustomerStreet

CustomerStreet

CustomerCity

CustomerCity

CustomerState

CustomerState

CustomerZipcode

CustomerZipcode

CustomerNumber

CustomerNumber

CustomerPhone

CustomerPhone

Order DateOrder Date

Order NumberOrder

NumberCustomerNumber

CustomerNumber

Sales TaxSales Tax

Order SubtotalOrder

Subtotal

ShippingShipping Order TotalOrder Total

Product ID + Order

Number

Product ID + Order

Number

QuantityQuantity Unit PriceUnit Price

Product IDProduct ID DescriptionDescription

Características de um Bom Modelo de Dados

Característica Descrição

GráficaUm bom modelo de dados deve ter uma representação gráfica correcta, quer das entidades quer

dos seus relacionamentos

RigorosoUm bom modelo deve ser rigorso na identificação de todas as entidades e seus relacionamentos

bem como na identificação e especificação dos atributos associados a cada entidade.

DecomponívelUm bom modelo deve ser decomponível de modo que o nível de detalhe de cada entidade e

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).

Minimizar RedundânciaUm bom modelo de dados mostrará redundância mínima no que respeita a entidades, dados e

relacionamentos.

TransparênciaOs dados actuais e a estrutura física da base de dados devem ser discernidos a partir do modelo

de dados.

Facilidade de LeituraUm bom modelo de dados deve representar o que se passa no domínio do discurso e a sua

“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.

Tarefa extra-aula

Leitura da Sebenta “Concepção e Desenvolvimento de Bases de Dados”:

http://www2.ufp.pt/~amrocha/as0405



Modelacao de dados

Documents

Transcript of Modelacao de dados