Planeje o seu modelo de dados
Modelo de dados relacional
Fundamental à estrutura de um banco de dados é o conceito de MODELO DE DADOS = coleção de ferramentas conceituais para descrição de dados, relacionamentos de dados, semântica de dados e restrições de consistência.
1) Conceitos e Arquiteturas de SGBD’s
1.1 Modelos de Dados, Esquemas e Instâncias:
Um Modelo de Dados é um conjunto de conceitos que podem ser usados para descrever a estrutura de uma base de dados. Por estrutura de uma base de dados entende-se os tipos de dados, relacionamentos e restrições pertinentes aos dados. Muitos modelos de dados também definem um conjunto de operações para especificar como recuperar e modificar a base de dados.
1.2 Categorias de Modelos de Dados
Muitos modelos de dados têm sido propostos. Pode-se classificar os modelos de dados baseando-se nos tipos de conceitos que fornecem para descrever a estrutura da base de dados.
Modelos de Dados Conceituais ou de Alto-Nível fornecem conceitos próximos à percepção dos usuários. Já os Modelos de Dados Físicos ou de Baixo-Nível fornecem conceitos que descrevemos detalhes de como os dados são armazenados no computador.
Modelos de alto-nível utilizam conceitos tais como Entidades, Atributos e Relacionamentos. Uma entidade é um objeto que é representado na base de dados. Um atributo é uma ropriedade que descreve algum aspecto de um objeto. Relacionamentos entre objetos são facilmente representados em modelos de dados de alto-nível, que são algumas vezes chamados de Modelos Baseados em Objetos devido, principalmente, à sua característica de escreverem objetos e seus relacionamentos.
Modelos de Dados de Baixo-Nível descrevem como os dados são armazenados no computador, representando informações em formato de registros, ordem dos registros e caminho de acesso. Um Caminho de Acesso é uma estrutura de que facilita a busca de um registro particular na base de dados.
1.3 Esquemas e Instâncias
Em qualquer modelo de dados é importante distinguir entre descrição da base de dados da própria base de dados. A descrição de uma base de dados é chamada Esquema da Base de Dados. Um esquema de base de dados é especificado durante o projeto da base de dados, sendo que a expectativa de mudanças não é grande. A forma de visualização de um esquema é chamada Diagrama do Esquema. Muitos modelos de dados têm certas convenções para, diagramaticamente, mostrar esquemas especificados no modelo.
Os dados atualmente existentes em uma base de dados podem mudar com relativa freqüência. Os dados da base de dados em um particular momento do tempo são chamados Instâncias da Base de Dados (ou Ocorrências ou Estados). A base-esquema é algumas vezes chamada de Base-Intencional e uma instância é chamada de Base-Extensional do esquema.
2) Arquitetura e Independência de Dados de SGBD’s
2.1 Arquitetura “Three-Schema” (conhecida como arquitetura ANSI/SPARC - Tsichritzis e Klug, 1978)
A meta desta arquitetura é separar as aplicações de usuários da base de dados física. Nesta arquitetura, esquemas podem ser definidos em três níveis:
a. O nível interno tem um esquema interno que descreve a estrutura de armazenamento físico da base de dados. O esquema interno usa um modelo de dados físico e descreve todos os detalhes de armazenamento de dados e caminhos de acesso à base de dados;
b. O nível conceitual tem um esquema conceitual que descreve a estrutura de toda a base de dados. O esquema conceitual é uma descrição global da base de dados, que omite detalhes da estrutura de armazenamento físico e se concentra na descrição de entidades, tipos de dados, relacionamentos e restrições. Um modelo de dados de alto-nível ou um modelo de dados de implementação podem ser utilizados neste nível.
c. O nível externo ou visão possui esquemas externos ou visões de usuários. Cada esquema externo descreve a visão da base de dados de um grupo de usuários da base de dados. Cada visão descreve, tipicamente, a parte da base de dados que um particular grupo de usuários está interessado e esconde o resto da base de dados do mesmo. Um modelo de dados de alto-nível ou um modelo de dados de implementação podem ser usados neste nível.
fig. 1.: Ilustração da separação da base de dados do usuário
Muitos SGBD’s não separam os três níveis completamente. Pode acontecer que alguns SGBD’s incluam detalhes do nível interno no esquema conceitual. Em muitos SGBD’s que dão suporte à visões, os esquemas externos são especificados com o mesmo modelo de dados usado no nível conceitual. Note-se que os três esquemas são apenas descrições dos dados. 3) Independência de dados
Neste artigo procuro passar alguns conceitos importantes antes de entrar a fundo no modelo de dados. No desenvolvimento de um sistema ou de vários sistemas, é necessário gerenciar o banco de dados, que consiste em uma coleção de dados inter-relacionados. Um conjunto de dados, normalmente referenciado como “banco de dados”, contém informações sobre uma ou várias empresas. Seu principal objetivo é prover um ambiente adequado e eficiente para recuperar, armazenar e tratar informações. Pensando no gerenciamento destes dados envolvendo: definição das estruturas de armazenamento, técnicas de manipulação e maneiras de garantir a segurança dos dados, desenvolvi esse artigo baseando na necessidade da modelagem de dados.
Independência Lógica de Dados: É a capacidade de alterar o esquema conceitual sem ter que mudar os esquemas externos ou programas de aplicação. Pode-se mudar o esquema conceitual para expandir a base de dados, adicionando novos tipos de registros ou de ítens de dados, ou reduzir a base de dados removendo um tipo de registro ou ítens de dados. Neste último caso, esquemas externos que se referem a apenas aos dados remanescentes não devem ser afetados;
Independência Física de Dados: É a capacidade de alterar o esquema interno sem ter que alterar o esquema conceitual externo. Mudanças no esquema interno podem ser necessárias devido a alguma reorganização de arquivos físicos para melhorar o desempenho nas recuperações e/ou modificações. Após a reorganização, se nenhum dado foi adicionado ou perdido, não haverá necessidade de modificar o esquema conceitual.
4) Modelagem de Dados Usando o Modelo Entidade-Relacionamento (MER)
O MER é um modelo de dados conceitual de alto-nível. Assim, os conceitos do MER foram projetados para serem compreensíveis a usuários, descartando detalhes de como os dados são armazenados.
Atualmente, o MER é usado principalmente durante o processo de projeto da base de dados. Existem expectativas para que uma classe de SGBD’s baseados diretamente no MER esteja disponível no futuro.
fig. 2.: Ilustração conceitual de um Modelo de Dados
5) Conceitos do Modelo Entidade-Relacionamento
5.1 Entidades e Atributos
O objeto básico que o MER representa é a entidade. Uma entidade é algo do mundo real que possui uma existência independente. Uma entidade pode ser um objeto com uma existência física - uma pessoa, carro ou empregado - ou pode ser um objeto com existência conceitual - uma companhia, um trabalho ou um curso universitário. Cada entidade tem propriedades particulares, chamadas atributos, que o descrevem. Por exemplo, uma entidade empregado pode ser descrita pelo seu nome, o trabalho que realiza, idade, endereço e salário. Uma entidade em particular terá um valor para cada um de seus atributos. Os valores de atributos que descrevem cada entidade ocupam a maior parte dos dados armazenados na base de dados.
A figura abaixo ilustra duas entidades. A entidade EMPREGADO e1 tem quatro atributos: Nome, Endereço, Idade e Telefone residencial. Os seus valores são: “Renato Cleber”, R. 123 de Março, Belo Horizonte, MG, 30120-012”, “33” e “3321-2020”, respectivamente. A entidade companhia c1 tem três atributos: Nome, Sede e Presidente. Seus valores são: “Nonato Neves”, “Betim”, “Ricardo Chaves”.
fig. 3.: Ilustração com exemplo de entidades e atributos
Alguns atributos podem ser divididos em subpartes com significados independentes. Por exemplo, Endereço da entidade e1 pode ser dividido em Endereço da Rua, Cidade, Estado e CEP. Um atributo que é composto de outros atributos mais básicos é chamado composto. Já, atributos que não são divisíveis são chamados simples ou atômicos. Atributos compostos podem formar uma hierarquia:
fig. 4.: Ilustração com exemplo de entidades e atributos compostos
Atributos compostos são úteis quando os usuários referenciam o atributo composto como uma unidade e, em outros momentos, referenciam especificamente a seus componentes. Se o atributo composto for sempre referenciado como um todo, não existe razão para subdividi-lo em componentes elementares.
6) Diagrama Entidade-Relacionamento (DER)
A figura 5 ilustra um DER para o esquema da base de dados COMPANHIA. Os tipos de entidades tais como EMPREGADO, DEPARTAMENTO e PROJETO são mostrados em retângulos. Tipos de relacionamentos tais como TRABALHA-PARA, GERENCIA, CONTROLA e TRABALHA-EM são mostrados em losângulos interligados à tipos de entidades participantes. Atributos são mostrados em elipses conectadas à tipos de entidades ou relacionamentos. Os atributos-chaves são sublinhados.
fig. 5.: Ilustração do modelo conceitual desenvolvido no VISIO 2002
Clique aqui e visualize o modelo de dados acima no Visio 2002, salvo para visualização em WEB.
Na figura 5 são mostradas as razões de cardinalidade para cada tipo de relacionamento binário. A razão de cardinalidade de DEPARTAMENTO:EMPREGADO em GERENCIA é 1:1, para DEPARTAMENTO:EMPREGADO em TRABALHA-PARA é 1:N e M:N para TRABALHAEM. As restrições de participação parcial são especificadas por linhas simples. As linhas paralelas denotam participação total (dependência existencial).
7) O Modelo de Dados Relacional
O Modelo de Dados Relacional foi introduzido por Codd(1970). Entre os modelos de dados de implementação, o modelo relacional é o mais simples, com estrutura de dados uniforme e o mais formal.
7.1 Conceitos do Modelo Relacional
O modelo de dados relacional representa os dados da base de dados como uma coleção de relações. Informalmente, cada relação pode ser entendida como uma tabela ou um simples arquivo de registros.
Por exemplo, a base de dados de arquivos representada pela figura 6, é considerada estar no modelo relacional. Porém, existem diferenças importantes entre relações e arquivos.
fig. 6.: Ilustração de um Modelo Relacional
O nome da tabela e os nomes das colunas são usados para ajudar a interpretar o significado dos valores em cada linha da tabela. Por exemplo, na figura anterior, a primeira tabela é chamada ESTUDANTE porque cada linha representa o fato sobre uma particular entidade estudante. Os nomes das colunas - Nome, Número, Classe, Departamento - especificam como interpretar os valores em cada linha baseando-se nas colunas que cada um se encontra. Todos os valores de uma mesma coluna são, normalmente, do mesmo tipo.
8) Modelo físico
Nessa etapa serão desenhadas as estruturas lógicas do modelo Dimensional, com as definições de tabelas fatos e tabelas dimensão, relacionamentos, indexação, atributos de tabelas e implantação de regras. Nesse momento a equipe projetista deverá considerar o uso do SGBD Relacional da instalação como depósito das informações do armazém de dados, ou o uso de um SGBD Dimensional, caso essa seja a opção. Terminada a fase de especificação das estruturas dimensionais, no plano conceitual, passamos a definir as tabelas dentro do ambiente de gerência de Banco de Dados até atingir o estágio físico do projeto de modelagem de dados. Vários aspectos relacionados ao projeto físico de Banco de Dados deverão ser considerados para garantir performance no acesso às estruturas relacionais ou dimencionais.
No seu planejamento procure preocupar com os seguintes itens para um bom desempenho da sua aplicação:
Estimativa do tamanho do database; Criação de Espaços de Tabelas; Criação de Tabelas; Definição de campos chaves e restrições; Definição de índices e estruturas especiais para os acessos; Considerações sobre carga de tabelas; Aspectos de performance; Considerações sobre desenvolvimento de aplicações.
Observações relevantes no projeto físico:
Atenar para o tamanho limite de linhas para cada SGBD, tanto para o número de colunas permitido quanto para o tamanho em bytes; Atente para a definição default de valores nulos para campos, evitando a sua definição (nulo) em campos da tabela principal; A definição da restrição de chave primária (unique not null) forçará a unicidade da linha (não haverá duplicações), não permitindo valores nulos, e definirá a criação automática de um índice;
Exemplo de criação de tabelas no MS SQL Server
CREATE TABLE [dbo].[DEPARTAMENTO] ( [numero] [numeric](18, 0) NOT NULL , [nome] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL , [localizacao] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NULL ) ON [PRIMARY] GO CREATE TABLE [dbo].[DEPENDENTE] ( [Codigo] [numeric](18, 0) NOT NULL , [Nome] [char] (30) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL , [sexo] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NULL , [datanasc] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NULL , [relacao] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NULL , [codempregado] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL ) ON [PRIMARY] GO CREATE TABLE [dbo].[EMPREGADO] ( [nss] [numeric](18, 0) NOT NULL , [sexo] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NULL , [endereco] [char] (50) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL , [salario] [float] NOT NULL , [datanasc] [datetime] NOT NULL , [pnome] [char] (50) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL , [mnome] [char] (50) COLLATE SQL_Latin1_General_CP850_CI_AI NULL , [snome] [char] (50) COLLATE SQL_Latin1_General_CP850_CI_AI NULL , [codprojeto] [numeric](18, 0) NOT NULL , [coddepartamento] [numeric](18, 0) NOT NULL ) ON [PRIMARY] GO CREATE TABLE [dbo].[GERENCIA_PROJETO] ( [codigo] [numeric](18, 0) NOT NULL , [horas] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL , [codprojeto] [numeric](18, 0) NOT NULL , [codempregado] [numeric](18, 0) NOT NULL ) ON [PRIMARY] GO CREATE TABLE [dbo].[GERENCIA_RH] ( [codigo] [numeric](18, 0) NOT NULL , [datainicio] [datetime] NOT NULL , [codempregado] [numeric](18, 0) NOT NULL , [coddepartamento] [numeric](18, 0) NOT NULL ) ON [PRIMARY] GO CREATE TABLE [dbo].[PROJETO] ( [numero] [numeric](18, 0) NOT NULL , [nome] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL , [localizacao] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NULL , [codempregado] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL ) ON [PRIMARY] GO
Dicas: Como escrever comandos em SQL:
Podem estar em uma ou mais linhas. Cláusulas são colocadas em linhas diferentes, usualmente. Pode-se utilizar tabulação para identação. Linhas de comando não podem ser hifenizadas. Comandos em SQL não são “Case sensitive”. O SQL trabalha com prompt e buffer. Utilizamos o ponto-e-vírgula no final da última linha de comando.
Conclusão
Desenvolvendo o seu projeto de banco de dados, de acordo com o artigo, é importante passar no mínimo por 3 fases: Modelo Conceitual, Modelo de Entidade e Relacionamento, chegando até ao Modelo Físico. Essas são as 3 básicas etapas, de um projeto de modelagem de dados.
Quando iniciar o seu projeto de um sistema, é importante alem de planejar o próprio sistema, através de UML ou outros modelagens, planeje também o seu modelo de dados. Preocupando com todas as fases do projeto, no futuro você terá um resultado acima do esperado.
Créditos: linhadecódigo
Fundamental à estrutura de um banco de dados é o conceito de MODELO DE DADOS = coleção de ferramentas conceituais para descrição de dados, relacionamentos de dados, semântica de dados e restrições de consistência.
1) Conceitos e Arquiteturas de SGBD’s
1.1 Modelos de Dados, Esquemas e Instâncias:
Um Modelo de Dados é um conjunto de conceitos que podem ser usados para descrever a estrutura de uma base de dados. Por estrutura de uma base de dados entende-se os tipos de dados, relacionamentos e restrições pertinentes aos dados. Muitos modelos de dados também definem um conjunto de operações para especificar como recuperar e modificar a base de dados.
1.2 Categorias de Modelos de Dados
Muitos modelos de dados têm sido propostos. Pode-se classificar os modelos de dados baseando-se nos tipos de conceitos que fornecem para descrever a estrutura da base de dados.
Modelos de Dados Conceituais ou de Alto-Nível fornecem conceitos próximos à percepção dos usuários. Já os Modelos de Dados Físicos ou de Baixo-Nível fornecem conceitos que descrevemos detalhes de como os dados são armazenados no computador.
Modelos de alto-nível utilizam conceitos tais como Entidades, Atributos e Relacionamentos. Uma entidade é um objeto que é representado na base de dados. Um atributo é uma ropriedade que descreve algum aspecto de um objeto. Relacionamentos entre objetos são facilmente representados em modelos de dados de alto-nível, que são algumas vezes chamados de Modelos Baseados em Objetos devido, principalmente, à sua característica de escreverem objetos e seus relacionamentos.
Modelos de Dados de Baixo-Nível descrevem como os dados são armazenados no computador, representando informações em formato de registros, ordem dos registros e caminho de acesso. Um Caminho de Acesso é uma estrutura de que facilita a busca de um registro particular na base de dados.
1.3 Esquemas e Instâncias
Em qualquer modelo de dados é importante distinguir entre descrição da base de dados da própria base de dados. A descrição de uma base de dados é chamada Esquema da Base de Dados. Um esquema de base de dados é especificado durante o projeto da base de dados, sendo que a expectativa de mudanças não é grande. A forma de visualização de um esquema é chamada Diagrama do Esquema. Muitos modelos de dados têm certas convenções para, diagramaticamente, mostrar esquemas especificados no modelo.
Os dados atualmente existentes em uma base de dados podem mudar com relativa freqüência. Os dados da base de dados em um particular momento do tempo são chamados Instâncias da Base de Dados (ou Ocorrências ou Estados). A base-esquema é algumas vezes chamada de Base-Intencional e uma instância é chamada de Base-Extensional do esquema.
2) Arquitetura e Independência de Dados de SGBD’s
2.1 Arquitetura “Three-Schema” (conhecida como arquitetura ANSI/SPARC - Tsichritzis e Klug, 1978)
A meta desta arquitetura é separar as aplicações de usuários da base de dados física. Nesta arquitetura, esquemas podem ser definidos em três níveis:
a. O nível interno tem um esquema interno que descreve a estrutura de armazenamento físico da base de dados. O esquema interno usa um modelo de dados físico e descreve todos os detalhes de armazenamento de dados e caminhos de acesso à base de dados;
b. O nível conceitual tem um esquema conceitual que descreve a estrutura de toda a base de dados. O esquema conceitual é uma descrição global da base de dados, que omite detalhes da estrutura de armazenamento físico e se concentra na descrição de entidades, tipos de dados, relacionamentos e restrições. Um modelo de dados de alto-nível ou um modelo de dados de implementação podem ser utilizados neste nível.
c. O nível externo ou visão possui esquemas externos ou visões de usuários. Cada esquema externo descreve a visão da base de dados de um grupo de usuários da base de dados. Cada visão descreve, tipicamente, a parte da base de dados que um particular grupo de usuários está interessado e esconde o resto da base de dados do mesmo. Um modelo de dados de alto-nível ou um modelo de dados de implementação podem ser usados neste nível.
fig. 1.: Ilustração da separação da base de dados do usuário
Muitos SGBD’s não separam os três níveis completamente. Pode acontecer que alguns SGBD’s incluam detalhes do nível interno no esquema conceitual. Em muitos SGBD’s que dão suporte à visões, os esquemas externos são especificados com o mesmo modelo de dados usado no nível conceitual. Note-se que os três esquemas são apenas descrições dos dados. 3) Independência de dados
Neste artigo procuro passar alguns conceitos importantes antes de entrar a fundo no modelo de dados. No desenvolvimento de um sistema ou de vários sistemas, é necessário gerenciar o banco de dados, que consiste em uma coleção de dados inter-relacionados. Um conjunto de dados, normalmente referenciado como “banco de dados”, contém informações sobre uma ou várias empresas. Seu principal objetivo é prover um ambiente adequado e eficiente para recuperar, armazenar e tratar informações. Pensando no gerenciamento destes dados envolvendo: definição das estruturas de armazenamento, técnicas de manipulação e maneiras de garantir a segurança dos dados, desenvolvi esse artigo baseando na necessidade da modelagem de dados.
Independência Lógica de Dados: É a capacidade de alterar o esquema conceitual sem ter que mudar os esquemas externos ou programas de aplicação. Pode-se mudar o esquema conceitual para expandir a base de dados, adicionando novos tipos de registros ou de ítens de dados, ou reduzir a base de dados removendo um tipo de registro ou ítens de dados. Neste último caso, esquemas externos que se referem a apenas aos dados remanescentes não devem ser afetados;
Independência Física de Dados: É a capacidade de alterar o esquema interno sem ter que alterar o esquema conceitual externo. Mudanças no esquema interno podem ser necessárias devido a alguma reorganização de arquivos físicos para melhorar o desempenho nas recuperações e/ou modificações. Após a reorganização, se nenhum dado foi adicionado ou perdido, não haverá necessidade de modificar o esquema conceitual.
4) Modelagem de Dados Usando o Modelo Entidade-Relacionamento (MER)
O MER é um modelo de dados conceitual de alto-nível. Assim, os conceitos do MER foram projetados para serem compreensíveis a usuários, descartando detalhes de como os dados são armazenados.
Atualmente, o MER é usado principalmente durante o processo de projeto da base de dados. Existem expectativas para que uma classe de SGBD’s baseados diretamente no MER esteja disponível no futuro.
fig. 2.: Ilustração conceitual de um Modelo de Dados
5) Conceitos do Modelo Entidade-Relacionamento
5.1 Entidades e Atributos
O objeto básico que o MER representa é a entidade. Uma entidade é algo do mundo real que possui uma existência independente. Uma entidade pode ser um objeto com uma existência física - uma pessoa, carro ou empregado - ou pode ser um objeto com existência conceitual - uma companhia, um trabalho ou um curso universitário. Cada entidade tem propriedades particulares, chamadas atributos, que o descrevem. Por exemplo, uma entidade empregado pode ser descrita pelo seu nome, o trabalho que realiza, idade, endereço e salário. Uma entidade em particular terá um valor para cada um de seus atributos. Os valores de atributos que descrevem cada entidade ocupam a maior parte dos dados armazenados na base de dados.
A figura abaixo ilustra duas entidades. A entidade EMPREGADO e1 tem quatro atributos: Nome, Endereço, Idade e Telefone residencial. Os seus valores são: “Renato Cleber”, R. 123 de Março, Belo Horizonte, MG, 30120-012”, “33” e “3321-2020”, respectivamente. A entidade companhia c1 tem três atributos: Nome, Sede e Presidente. Seus valores são: “Nonato Neves”, “Betim”, “Ricardo Chaves”.
fig. 3.: Ilustração com exemplo de entidades e atributos
Alguns atributos podem ser divididos em subpartes com significados independentes. Por exemplo, Endereço da entidade e1 pode ser dividido em Endereço da Rua, Cidade, Estado e CEP. Um atributo que é composto de outros atributos mais básicos é chamado composto. Já, atributos que não são divisíveis são chamados simples ou atômicos. Atributos compostos podem formar uma hierarquia:
fig. 4.: Ilustração com exemplo de entidades e atributos compostos
Atributos compostos são úteis quando os usuários referenciam o atributo composto como uma unidade e, em outros momentos, referenciam especificamente a seus componentes. Se o atributo composto for sempre referenciado como um todo, não existe razão para subdividi-lo em componentes elementares.
6) Diagrama Entidade-Relacionamento (DER)
A figura 5 ilustra um DER para o esquema da base de dados COMPANHIA. Os tipos de entidades tais como EMPREGADO, DEPARTAMENTO e PROJETO são mostrados em retângulos. Tipos de relacionamentos tais como TRABALHA-PARA, GERENCIA, CONTROLA e TRABALHA-EM são mostrados em losângulos interligados à tipos de entidades participantes. Atributos são mostrados em elipses conectadas à tipos de entidades ou relacionamentos. Os atributos-chaves são sublinhados.
fig. 5.: Ilustração do modelo conceitual desenvolvido no VISIO 2002
Clique aqui e visualize o modelo de dados acima no Visio 2002, salvo para visualização em WEB.
Na figura 5 são mostradas as razões de cardinalidade para cada tipo de relacionamento binário. A razão de cardinalidade de DEPARTAMENTO:EMPREGADO em GERENCIA é 1:1, para DEPARTAMENTO:EMPREGADO em TRABALHA-PARA é 1:N e M:N para TRABALHAEM. As restrições de participação parcial são especificadas por linhas simples. As linhas paralelas denotam participação total (dependência existencial).
7) O Modelo de Dados Relacional
O Modelo de Dados Relacional foi introduzido por Codd(1970). Entre os modelos de dados de implementação, o modelo relacional é o mais simples, com estrutura de dados uniforme e o mais formal.
7.1 Conceitos do Modelo Relacional
O modelo de dados relacional representa os dados da base de dados como uma coleção de relações. Informalmente, cada relação pode ser entendida como uma tabela ou um simples arquivo de registros.
Por exemplo, a base de dados de arquivos representada pela figura 6, é considerada estar no modelo relacional. Porém, existem diferenças importantes entre relações e arquivos.
fig. 6.: Ilustração de um Modelo Relacional
O nome da tabela e os nomes das colunas são usados para ajudar a interpretar o significado dos valores em cada linha da tabela. Por exemplo, na figura anterior, a primeira tabela é chamada ESTUDANTE porque cada linha representa o fato sobre uma particular entidade estudante. Os nomes das colunas - Nome, Número, Classe, Departamento - especificam como interpretar os valores em cada linha baseando-se nas colunas que cada um se encontra. Todos os valores de uma mesma coluna são, normalmente, do mesmo tipo.
8) Modelo físico
Nessa etapa serão desenhadas as estruturas lógicas do modelo Dimensional, com as definições de tabelas fatos e tabelas dimensão, relacionamentos, indexação, atributos de tabelas e implantação de regras. Nesse momento a equipe projetista deverá considerar o uso do SGBD Relacional da instalação como depósito das informações do armazém de dados, ou o uso de um SGBD Dimensional, caso essa seja a opção. Terminada a fase de especificação das estruturas dimensionais, no plano conceitual, passamos a definir as tabelas dentro do ambiente de gerência de Banco de Dados até atingir o estágio físico do projeto de modelagem de dados. Vários aspectos relacionados ao projeto físico de Banco de Dados deverão ser considerados para garantir performance no acesso às estruturas relacionais ou dimencionais.
No seu planejamento procure preocupar com os seguintes itens para um bom desempenho da sua aplicação:
Estimativa do tamanho do database; Criação de Espaços de Tabelas; Criação de Tabelas; Definição de campos chaves e restrições; Definição de índices e estruturas especiais para os acessos; Considerações sobre carga de tabelas; Aspectos de performance; Considerações sobre desenvolvimento de aplicações.
Observações relevantes no projeto físico:
Atenar para o tamanho limite de linhas para cada SGBD, tanto para o número de colunas permitido quanto para o tamanho em bytes; Atente para a definição default de valores nulos para campos, evitando a sua definição (nulo) em campos da tabela principal; A definição da restrição de chave primária (unique not null) forçará a unicidade da linha (não haverá duplicações), não permitindo valores nulos, e definirá a criação automática de um índice;
Exemplo de criação de tabelas no MS SQL Server
CREATE TABLE [dbo].[DEPARTAMENTO] ( [numero] [numeric](18, 0) NOT NULL , [nome] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL , [localizacao] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NULL ) ON [PRIMARY] GO CREATE TABLE [dbo].[DEPENDENTE] ( [Codigo] [numeric](18, 0) NOT NULL , [Nome] [char] (30) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL , [sexo] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NULL , [datanasc] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NULL , [relacao] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NULL , [codempregado] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL ) ON [PRIMARY] GO CREATE TABLE [dbo].[EMPREGADO] ( [nss] [numeric](18, 0) NOT NULL , [sexo] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NULL , [endereco] [char] (50) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL , [salario] [float] NOT NULL , [datanasc] [datetime] NOT NULL , [pnome] [char] (50) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL , [mnome] [char] (50) COLLATE SQL_Latin1_General_CP850_CI_AI NULL , [snome] [char] (50) COLLATE SQL_Latin1_General_CP850_CI_AI NULL , [codprojeto] [numeric](18, 0) NOT NULL , [coddepartamento] [numeric](18, 0) NOT NULL ) ON [PRIMARY] GO CREATE TABLE [dbo].[GERENCIA_PROJETO] ( [codigo] [numeric](18, 0) NOT NULL , [horas] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL , [codprojeto] [numeric](18, 0) NOT NULL , [codempregado] [numeric](18, 0) NOT NULL ) ON [PRIMARY] GO CREATE TABLE [dbo].[GERENCIA_RH] ( [codigo] [numeric](18, 0) NOT NULL , [datainicio] [datetime] NOT NULL , [codempregado] [numeric](18, 0) NOT NULL , [coddepartamento] [numeric](18, 0) NOT NULL ) ON [PRIMARY] GO CREATE TABLE [dbo].[PROJETO] ( [numero] [numeric](18, 0) NOT NULL , [nome] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL , [localizacao] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NULL , [codempregado] [char] (10) COLLATE SQL_Latin1_General_CP850_CI_AI NOT NULL ) ON [PRIMARY] GO
Dicas: Como escrever comandos em SQL:
Podem estar em uma ou mais linhas. Cláusulas são colocadas em linhas diferentes, usualmente. Pode-se utilizar tabulação para identação. Linhas de comando não podem ser hifenizadas. Comandos em SQL não são “Case sensitive”. O SQL trabalha com prompt e buffer. Utilizamos o ponto-e-vírgula no final da última linha de comando.
Conclusão
Desenvolvendo o seu projeto de banco de dados, de acordo com o artigo, é importante passar no mínimo por 3 fases: Modelo Conceitual, Modelo de Entidade e Relacionamento, chegando até ao Modelo Físico. Essas são as 3 básicas etapas, de um projeto de modelagem de dados.
Quando iniciar o seu projeto de um sistema, é importante alem de planejar o próprio sistema, através de UML ou outros modelagens, planeje também o seu modelo de dados. Preocupando com todas as fases do projeto, no futuro você terá um resultado acima do esperado.
Créditos: linhadecódigo
Postagens
0 Comentários:
Postar um comentário