8. conjunto de arquivos integrados que atendem a um conjunto de sistemas
9. solução para evitar a redundância não controlada de informações
10. sistema de gerência de banco de dados (SGBD)
11. software que incorpora as funções de definição, recuperacão e alteracão de dados em um banco de dados
12. conceitual
13. lógico
14. projeto de BD - fases
15. modelo de dados que representa a estrutura de dados de um banco de dados conforme vista pelo usuário do SGBD
16. modelo de dados abstrato, que descreve a estrutura de um banco de dados de forma independente de um SGBD particular
17. como modelo de organização pode ser:
18. modelo abstrato da organização, que define as entidades da organização que tem informações armazenadas no banco de dados
19. modelo abstrato do banco de dados, que define que arquivos (tabelas) farão parte do banco de dados.
20. 1º modelagem conceitual
21. é construído um modelo na forma de um diagrama entidade-relacionamento. Este modelo captura as necessidades da organização em termos de armazenamento de dados independentemente de implementação.
22. 2º projeto lógico
23. objetiva transformar o modelo conceitual obtido na primeira fase em um modelo lógico. O modelo lógico define como o banco de dados será implementado em um SGBD específico.
24. 3º projeto físico
25. o modelo do banco de dados é enriquecido com detalhes que influenciam no desempenho do banco de dados, mas não interferem em sua funcionalidade. O modelo obtido neste passo é o modelo físico do banco de dados.
26. entidade
27. conjunto de objetos da realidade modelada sobre os quais deseja-se manter informações no banco de dados
28. relacionamento
29. conjunto de associações entre ocorrências de entidades
30. papel de entidade em relacionamento
31. função que uma instância da entidade cumpre dentro de uma instância do relacionamento
32. cardinalidade (mínima, máxima) de entidade em relacionamento
33. número (mínimo, máximo) de ocorrências de entidade associadas a uma ocorrência da entidade em questão através do relacionamento
34. relacionamento binário
35. aquele cujas ocorrências contêm duaso corrências de entidade. em um relacionamento binário entre duas entidades A e B, a cardinalidade máxima de A em R indica quantas ocorrências de B podem estar associadas a cada ocorrência de A.Podemos classificar os relacionamentos binários em n:n, 1:n e 1:1.
36. relacionamento ternário
37. No caso de um relacionamento ternário, a cardinalidade refere-se a pares de entidades. Em um relacionamento R entre três entidades A, B e C, a cardinalidade máxima de A e B dentro de R indica quantas ocorrências de C podem estar associadas a um par de ocorrências de A e B.
38. cardinalidade mínima
39. Para fins de projeto de BD, consideram-se apenas duas cardinalidades mínimas: a car- dinalidade mínima 0 e a cardinalidade mínima 1 (associação obrigatória).
40. atributo
41. dado que é associado a cada ocorrência de uma entidade ou de um relacionamento
42. identificador de entidade
43. conjunto de um ou mais atributos e relacionamentos cujos valores servem para distinguir uma ocorrência da entidade das demais ocorrências da mesma entidade. há casos em que o identificador de uma entidade é composto não somente por atributos da própria entidade, mas também por relacionamentos dos quais a entidade participa (relacionamento identificador).
44. O identificador deve ser mínimo. Cada entidade deve possuir um único identificador.
45. generalização/especialização
46. conceito do qual propriedades podem ser atribuídas a entidades. pode ser classificada em dois tipos, total ou parcial, de acordo com a obrigatoriedade ou não de a cada ocorrência da entidade genérica corresponder uma ocorrência da entidade especializada.Generalização/especialização exclusiva significa que, em uma hierarquia de generalização/especialização, uma ocorrência de entidade genérica é especializada no máximo uma vez, nas folhas da árvore de generalização/espe- cialização.Já a generalização/especialização compartilhada indica que, em uma hierar- quia de generalização/especialização, uma ocorrência de entidade genérica pode aparecer em várias entidades nas folhas da árvore de generalização/ especialização.
47. entidade associativa
48. Na modelagem ER não foi prevista a possibilidade de associar uma entidade com um relaciona- mento ou então de associar dois relacionamentos entre si. Na prática, quan- do estamos construindo um novo modelo ER ou modificando um modelo ER existente, surgem situações em que é desejável permitir a associação de uma entidade a um relacionamento.
48.1. determinando construções - critérios que podem ser usados na escolha de construções de modelagem.
49. Modelos ER têm poder de expressão limitado; Diferentes modelos podem ser equivalentes; Um modelo ER é um modelo formal
50. propriedades dos modelos
51. atributo versus entidade relacionada
52. Caso o objeto cuja modelagem está em discussão esteja vinculado a outros objetos, o objeto deve ser modelado como entidade.Caso contrário, o objeto pode ser modelado como atributo.
53. Quando o conjunto de valores de um determinado objeto é fixo durante toda a vida do sistema, ele pode ser modelado como atributo.Quando existem transa- ções no sistema, que alteram o conjunto de valores do objeto, o mesmo não deve ser modelado como atributo.
54. atributo versus especialização
55. Uma especialização deve ser usada quando sabe-se que as classes especializa- das de entidades possuem propriedades (atributos, relacionamentos, generalizações, especializações) particulares.
56. entidade relacionada versus especialização
57. um objeto somente pode ser tratado como especialização de outro quando o objeto especializado herda a chave primária do objeto genérico. Isso significa, também, que para cada ocorrência do objeto genérico pode existir no máximo uma ocorrência na especialização.
58. atributos opcionais e multivalorados
59. atributos opcionais indicam subconjuntos de entidades que são modelados mais corretamente através de especializações.Assim, toda vez que aparecer um atributo opcional, é recomendável verificar se a modelagem através de entidades especializadas não é mais conveniente.
60. atributos multivalorados são considerados indesejáveis por mui- tos autores pelas seguintes razões:Nos SGBDs relacionais que seguem o padrão SQL/2, atributos multivalorados não possuem implementação direta; Atributos multivalorados podem induzir a um erro de modelagem, que é o de ocultar entidades e relacionamentos em atributos multivalorados;
61. verificação do modelo
62. Um modelo deve ser correto; completo; livre de redundância; refletir o aspecto temporal;
63. composição de um banco de dados relacional
64. tabela conjunto não ordenado de linhas (tuplas, na terminologia acadêmica).
65. 5. transformações entre modelos
66. entidade isolada e entidade sem atributos
67. Uma entidade isolada é uma entidade que não apresenta relacionamento com outras entidades. Outra situação que não está incorreta, mas deve ser investigada, é a de uma entidade sem atributos.
68. estabelecimento de padrões
69. variantes da abordagem ER
70. notação engenharia de informações
71. a abordagem UML,
72. notação européia para cardinalidades
73. uso de ferramentas de modelagem
74. CASE (Computer Aided Software Engineering).
75. programas de propósito geral
76. estratégias de modelagem
77. partindo de descrições de dados existentes
78. partindo do conhecimento de pessoas (estratégia descendente, estratégia inside-out).
79. chave- conceito básico para identificar linhas e estabelecer relações entre linhas de tabelas de um banco de dados relacional
80. chave primária é uma coluna ou uma combinação de colunas cujos valo- res distinguem uma linha das demais dentro de uma tabela.
81. Uma chave estrangeira é uma coluna ou uma combinação de colunas, cujos valores aparecem necessariamente na chave primária de uma tabela. A chave estrangeira é o mecanismo que permite a implementação de relacionamentos em um banco de dados relacional.
82. Em alguns casos, mais de uma coluna ou combinações de colunas podem servir para distinguir uma linha das demais. Uma das colunas (ou combinação de colunas) é escolhida como chave primária. As demais colunas ou combi- nações são denominadas chaves alternativas.
83. Quando uma tabela do banco de dados é definida, para cada coluna da tabela deve ser especificado um conjunto de valores (alfanumérico, numérico,...) que os campos da respectiva coluna podem assumir. Este conjunto de valores é chamado de domínio da coluna ou domínio do campo.
84. Além disso, deve ser especificado se os campos da coluna podem estar vazios (null1 em inglês) ou não. Estar vazio indica que o campo não recebeu valor de seu domínio.
85. Uma restrição de integridade é uma regra de consistência de dados que é garantida pelo próprio SGBD.
86. modelo de banco de dados relacional
87. tabelas que formam o banco de dados,
88. colunas que as tabelas possuem
89. restrições de integridade
90. esquema textual
91. representação de esquema de banco de dados relacional
92. esquema diagramático
93. transformação ER para relacional
94. objetivos básicos do projeto de BD:
95. Obter um banco de dados que permita boa performance de instruções de consulta e alteração do banco de dados.
96. Obter um banco de dados que simplifique o desenvolvimento e a manu- tenção de aplicações.
97. regras de tradução tem por base os principios
98. Evitar junções – Ter os dados necessários a uma consulta em uma única linha
99. Diminuir o número de chaves – Para a implementação eficiente do controle da unicidade da chave primária ou chave alternativa, o SGBD usa normalmente uma estrutura de acesso auxiliar, um índice.
100. Evitar campos opcionais – Campos opcionais são campos que podem assumir o valor vazio (NULL em SQL).
101. processo de projeto lógico, ou seja, os passos envolvidos na transformação de um modelo conceitual ER em um modelo lógico relacional.
102. implementação inicial de entidades e respectivos atributos
103. Implementação de relacionamentos e respectivos atributos
104. Implementação de generalizações/especializações
105. refinamento do modelo
106. engenharia reversa de modelos relacionais
107. um processo de abstração, que parte de um modelo de implementação e resulta em um modelo conceitual, que descreve abstratamente a implemen- tação em questão. O termo engenharia reversa vem do fato de usar-se, como ponto de partida do processo, um produto implementado (o modelo de im- plementação) para obter sua especificação (o modelo conceitual).No caso de banco de dados, fala-se de engenharia reversa quando modelos de dados mais ricos em detalhes de implementação são transformados em modelos de dados mais abstratos.
108. O processo de engenharia reversa de um modelo relacional consta dos seguintes passos:
109. Identificação da construção ER correspondente a cada tabela
110. Definição de relacionamentos 1:n e 1:1
111. Definição de atributos
112. Definição de identificadores de entidades e relacionamentos
