diff --git a/aulas/04.md b/aulas/04.md
index 0ef83a9c..7a1e340b 100644
--- a/aulas/04.md
+++ b/aulas/04.md
@@ -327,7 +327,7 @@ TOTAL                      54      2    96%
 
 Neste caso, podemos ver que todos os nossos testes passaram com sucesso. Isso significa que nossa funcionalidade de criação de usuário está funcionando corretamente e que nosso modelo de usuário está sendo corretamente persistido no banco de dados.
 
-Embora tudo esteja se encaixando bem, esse teste não é muito legal, pois não faz a validação do objeto como um todo. Conseguimos garantir que toda a estrutura do bando de dados funciona, porém, não conseguimos garantir ainda que todos os valores estão corretos.
+Embora tudo esteja se encaixando bem, esse teste não é muito legal, pois não faz a validação do objeto como um todo. Conseguimos garantir que toda a estrutura do banco de dados funciona, porém, não conseguimos garantir ainda que todos os valores estão corretos.
 
 ## Eventos do ORM
 
@@ -350,7 +350,7 @@ Isso nos permite modificar os dados antes ou depois de determinadas operações
 
 Por exemplo, nosso modelo de `User` não permite que sejam enviados os campos `id` e `created_at` no momento em que a instância de `User` é criada. Por conta da restrição `init=False` no `mapped_column`.
 
-Escrever testes com essa restrição pode nos trazer algumas dificuldades no momento das validações (asserts). Então vamos programar um evento para acontecer **antes** que o dado seja inserido no banco de dados.
+Ao escrever testes, essa restrição pode nos trazer algumas dificuldades no momento das validações (asserts). Então vamos programar um evento para acontecer **antes** que o dado seja inserido no banco de dados.
 
 ```mermaid
 flowchart TD
@@ -411,7 +411,7 @@ def _mock_db_time(*, model, time=datetime(2024, 1, 1)): #(2)!
 1. O decorador `#!python @contextmanager` cria um gerenciador de contexto para que a função `_mock_db_time` seja usada com um bloco `#!python with`. Caso você não tenha experiência com gerenciadores de contexto, você pode assistir a [essa Live](https://youtu.be/fR73UVNXb04){:target="_blank"}.
 2. Todos os parâmetros após `*` devem ser chamados de forma nomeada, para ficarem explícitos na função. Ou seja `mock_db_time(model=User)`. Os parâmetros não podem ser chamados de forma posicional `_mock_db_time(User)`, isso acarretará em um erro.
 3. Função para alterar alterar o método `created_at` do objeto de target.
-4. `event.listen` adiciona um evento relação a um `model` que será passado a função. Esse evento é o `before_insert`, ele executará uma função (hook) antes de inserir o registro no banco de dados. O hook é a função `fake_time_handler`.
+4. `event.listen` adiciona um evento relação a um `model` que será passado a função. Esse evento é o `before_insert`, ele executará uma função (hook) antes de inserir o registro no banco de dados. O hook é a função `fake_time_hook`.
 5. Retorna o datetime na abertura do gerenciamento de contexto.
 6. Após o final do gerenciamento de contexto o hook dos eventos é removido.
 
@@ -468,7 +468,7 @@ O teste permanece praticamente igual, com a diferença de que todas as operaçõ
 
 Isso faz com que durante o `commit`, quando os objetos são persistidos da sessão para o banco de dados, o evento de `before_insert` seja executado para cada objeto do modelo passado em `mock_db_time(model=*MODEL*)`.
 
-Por conta do campo `created_at` agora ser determinístico podemos fazer uma comparação completa dos campos. 
+Por conta do campo `created_at` agora ser determinístico podemos fazer uma comparação completa dos campos.
 
 Para simplificar a comparação de todos os campos, como nossos objetos de modelo são dataclasses, a função `dataclass.asdict()`, converte uma dataclass para um dicionário:
 
@@ -571,7 +571,7 @@ Com isso, a estrutura do nosso projeto sofre algumas alterações e novos arquiv
    └── test_db.py
 ```
 
-No arquivo `alembic.ini`: ficam as configurações gerais das nossas migrações. Na pasta `migrations` foram criados um arquivo chamado `env.py`, esse arquivo é responsável por como as migrações serão feitas, e o arquivo `script.py.mako` é um template para as novas migrações.
+No arquivo `alembic.ini`: ficam as configurações gerais das nossas migrações. Na pasta `migrations` foram criados dois arquivos, um chamado `env.py` que é responsável por como as migrações serão feitas, e o outro chamado `script.py.mako` que é um template para as novas migrações.
 
 ### Criando uma migração automática
 
@@ -701,7 +701,7 @@ Vamos acessar o console do sqlite e verificar se isso foi feito. Precisamos cham
 ```shell title="$ Execução no terminal!"
 sqlite3 database.db
 ```
-	
+
 ??? tip "Caso não tenha o SQLite instalado na sua máquina:"
 
 	```shell title="Arch"