PESQUISANDO, DEFININDO E FUNDAMENTANDO CONCEITOS
Por: Evandro.2016 • 12/11/2018 • 2.225 Palavras (9 Páginas) • 316 Visualizações
...
FILO (First In Last Out): Termo empregado na caracterização de Pilha que também pode ser classificado como uma estrutura de dados de comprimento variável, onde o primeiro elemento inserido é o último a ser eliminado ou retirado da pilha, e consequentemente o último elemento inserido é o primeiro a ser eliminado (LIFO – Last In First Out).
A melhor forma de exemplificar o conceito de pilhas é analisando uma pilha de pratos guardados em um armário, conforme as pessoas vão utilizando-os pega sempre o prato que se encontra no topo da pilha, assim como, quando um novo prato vai ser guardado, é colocado no topo. Pelo fato de apenas uma das extremidades da pilha está acessível.
Tipos de Alocações
Alocação Simplesmente Encadeadas: Esse tipo de alocação organiza os elementos na lista de uma maneira que apenas um ponteiro é empregado em meio a uma sucessão de nós onde cada nó aponta para o próximo nó da lista, até que o ponteiro aponte para o último nó da lista, quando isso acontece o ponteiro retorna para o primeiro nó da lista, caso esta referência seja NULL, significa que a lista esta vazia.
[pic 7]
Alocação Duplamente encadeadas: Esse tipo de alocação são listas que, além de cada elemento possuir um campo que indica o elemento seguinte, também possui um campo que indicam aquele que o antecede, ou seja, cada elemento é ligado ao seu sucessor e ao seu predecessor.
[pic 8]
Entre estas formas de alocações existe uma questão que envolve desempenho, flexibilidade e requisitos de alocação de memória, relacionados com a opção que fazemos por uma ou outra estrutura de dados. Tratando-se da forma de lista simplesmente encadeada, os nós são claramente menores e emprega-se apenas um ponteiro por dado armazenado, e a flexibilidade de deslocamento entre os nós é menor, pois segue um só sentido, e mesmo o desempenho pode ser menor no caso de operações como a inserção no final da lista. Por outro lado as listas duplamente encadeadas ocupam mais espaço na memória, já que se empregam dois ponteiros para cada dado, e são bem mais flexíveis e eficientes em certas operações, por exemplo, na inserção/remoção do final da lista. Entretanto, como atualmente a fartura da capacidade de memória de armazenamento, não é um problema para os desenvolvedores, eu recomendaria a alocação duplamente encadeada.
3.2 Conceituando as propriedades ACID de uma transação de Banco de Dados
Dentre as diversas funcionalidades de um SGBD - Sistema de Gerenciamento de Banco de Dados, existem determinadas propriedades que são fundamentais e de ordem obrigatória para que um SGBD de fato seja considerado verdadeiro. Estas propriedades são denominadas pelo termo ACID composto por 4 fundamentos de igual importância: Atomicidade, Consistência, Isolamento e Durabilidade.
- Atomicidade
Uma transação deverá ser realizada por inteiro, caso contrário o SGBD não poderá confirmar a mesma, é por isso que uma transação é atômica, pelo fato de ser indivisível. Uma transação poderá conter inúmeras operações de alteração de dados, porém só poderá ser confirmada caso todas as operações sejam concluídas, senão nenhuma delas poderá ser realizada, de modo a garantir a atomicidade da transação.
- Consistência
Essa propriedade tem a finalidade de garantir que os dados guardados no SGBD estejam todos consistentes e que ao término de cada nova transação, os dados passaram a outra forma consistente, de modo que todas as regras de negócio devem continuar sendo executadas e cumpridas.
- Isolamento
Representa a integridade das transações, cada transação deve ser íntegra e isolada, ou seja, em meio a concorrência das diversas transações que acontecem no SGBD, cada uma delas devem acontecer de maneira isolada uma com as outras, cumprindo as regras de negócio durante a realização das operações na transação independentemente de existirem mais transações de maneira simultânea e, ao final delas, esta integridade deve permanecer.
- Durabilidade
Toda transação realizada e confirmada no banco de dados deve permanecer intácta, ou seja tem por obrigação ser durável, jamais poderá desaparecer do banco de dados sem que uma outra transação realize esta operação. Essa propriedade do SGBD deve garantir a durabilidade dos dados que foram gravados pelas transações e que não sejam perdidos ou danificados, mesmo diante de alguma falha no sistema, como travamento e queda de energia etc.
3.3 Uso de um banco de dados relacional com programação orientada a objetos
O funcionamento de um banco de dados relacional com programação orientada a objetos pode ser definido considerando dois universos distintos, o relacional e o orientado a objetos. No universo relacional os princípios matemáticos prevalecem com a finalidade de armazenar e gerenciar corretamente os dados, de modo seguro e se emprega a linguagem SQL que é empregada para indicar ao banco de dados “o que” fazer e não como fazer. Por outro lado no universo orientado a objetos empregamos as classes e métodos, aplicando-se princípios e fundamentados da engenharia de software que nos dizem “como” fazer. Com o ORM (Object Relational Mapping) acontece a ponte entre estes universos, ou seja, é ele quem vai permitir o armazenamento dos objetos no banco de dados, executando um mapeamento dos seus objetos para as tabelas do banco de dados.
Podemos constatar na ilustração anterior que existe um mapeamento da classe para o banco de dados e cada ORM tem suas particularidades, para gerar o SQL referente à inserção do objeto que corresponde a uma tabela no banco de dados e realiza a operação.
3.4 Significado de ORM – Mapeamento Objeto Relacional
ORM pode ser considerada uma técnica de mapeamento de objeto relacional que nos permite fazer uma relação dos objetos com os dados que os mesmos representam. Tem sido muito requisitada ultimamente e vem apresentando um crescimento bastante expressivo nos últimos anos, este crescimento tem se dado principalmente pelo fato de muitos programadores não se sentirem a vontade para desenvolver o código SQL. A utilização de um ORM, amplia a produtividade, pois deixa-se de escrever os comando SQL para deixar que o próprio ORM faça isto.
3.5
...