Index: P1-ConceptualModel/ERModel.md =================================================================== --- P1-ConceptualModel/ERModel.md (revision d8ce4e224bde01e8f87558691226298db515617e) +++ P1-ConceptualModel/ERModel.md (revision d8ce4e224bde01e8f87558691226298db515617e) @@ -0,0 +1,253 @@ +# Entity-Relationship Model v.01 + +## Diagram + +![ERModel_v01](ERModel_v01.png) + +Attachments for this page: `ERModel_v01.xml` (TerraER source) and `ERModel_v01.png` +(exported image). Open the source with TerraER 3.11: + +```sh +java -jar TerraER3.11.jar # then File → Open → ERModel_v01.xml +``` + +Notation: Chen. Rectangles are entity sets, diamonds are relationships, ellipses +are attributes, underlined ellipses are primary keys, the dashed ellipse is a +derived attribute. A double line between an entity set and a relationship marks +**total participation** (every instance of that entity set must participate); a +single line marks partial participation. + +Two deliberate modeling decisions worth stating up front: + +- **No foreign keys appear in the diagram.** Connections between entity sets are + expressed as relationships, per the notation. Foreign-key columns appear only + in the relational model in [RelationalDesign](../P2-RelationalDesign/RelationalDesign.md). +- **`Holds` and `Contains` are relationships, not entity sets.** Both are M:N and + both carry their own attributes, which is exactly what a Chen relationship is + for. They become tables (`holdings`, `watchlist_items`) only in P2. + +## Data requirements + +### Entity sets + +#### Users +Registered participants of the platform. Every action in the simulation is +attributed to a user, and the two balance attributes are what makes the +simulation work: cash that is free to trade is tracked separately from cash that +is currently committed to open positions, so the platform can refuse a purchase +without having to recompute the whole portfolio first. + +- **Candidate keys:** `{id}`, `{username}`, `{email}`. Primary key: **`id`**. + A surrogate UUID was chosen because it is opaque and stable — `username` and + `email` are both things a user may legitimately want to change later, and + every relationship in the diagram points at `Users`, so a mutable key would + propagate changes across the whole database. +- **Attributes:** + - `id` — UUID, required, primary key. + - `username` — text, max 50, required, unique. + - `email` — text, max 255, required, unique, must contain `@`. + - `full_name` — text, max 200, optional. + - `password_hash` — text, max 255, required. Never the password itself; the + prototype stores a SHA-256 hex digest. + - `available_balance` — numeric(18,4), required, default 0, must be ≥ 0. + - `invested_balance` — numeric(18,4), required, default 0, must be ≥ 0. + - `created_at` — timestamp with time zone, required, defaults to now. + - `updated_at` — timestamp with time zone, optional (null until first change). + +#### Cryptos +The catalog of crypto assets the platform knows about. Kept separate from +`Markets` because an asset exists independently of the pairs it is traded in — +the same asset can be quoted against several currencies, and a user's holding is +in the *asset*, not in a particular pair. + +- **Candidate keys:** `{id}`, `{symbol}`. Primary key: **`id`**, for the same + reason as in `Users`; `symbol` is kept as a unique natural key because that is + what users type and see. +- **Attributes:** + - `id` — UUID, required, primary key. + - `symbol` — text, max 20, required, unique (e.g. `BTC`). + - `name` — text, max 255, required (e.g. `Bitcoin`). + - `created_at` — timestamptz, required, defaults to now. + +#### Markets +A tradeable pair: one crypto asset quoted in one currency, e.g. BTC/USD. This is +where prices live, and it is the thing an order is placed *on*. Modeled as its +own entity set rather than an attribute of `Cryptos` because a market has its own +lifecycle — it can be deactivated without deleting the asset — and because +trades, candles and orders all reference the pair, not the asset. + +- **Candidate keys:** `{id}`, `{crypto_id, quote_currency}` — that pair is + unique by definition, since a given asset can only be quoted once per + currency. Primary key: **`id`**, so that the many entity sets referencing a + market carry one narrow column instead of a composite key. +- **Attributes:** + - `id` — UUID, required, primary key. + - `quote_currency` — text, exactly 3 characters, required, default `USD`. + - `is_active` — boolean, required, default true. Inactive markets are hidden + from the trading menus but keep their history. + - `created_at` — timestamptz, required, defaults to now. + +#### Orders +A user's instruction to buy or sell on a market. Needed as a separate entity set +because an order is a record of *intent* that outlives its execution: it keeps +the requested quantity and price even after it has been filled, which is what +makes the ledger auditable. + +- **Candidate keys:** `{id}` only. There is no natural key — the same user can + place two identical orders on the same market in the same second, and both are + legitimately distinct. Primary key: **`id`**. +- **Attributes:** + - `id` — UUID, required, primary key. + - `side` — text, required, restricted to `buy` or `sell`. + - `type` — text, required, restricted to `market` or `limit`. The prototype + executes only `market` orders; `limit` exists so the model does not have to + change when limit orders are implemented. + - `status` — text, required, restricted to `open`, `executed`, `cancelled`. + - `quantity` — numeric(20,4), required, must be > 0. + - `price` — numeric(18,6), optional — null for a market order until it fills, + then the fill price. + - `placed_at` — timestamptz, required, defaults to now. + - `executed_at` — timestamptz, optional, set when the order fills. + +#### Transactions +The financial ledger: every movement of virtual cash, in one place. This exists +so that a balance is never just a number someone edited — it is the sum of an +auditable list of entries, which is also what the "explain every step" goal of +the project needs. + +- **Candidate keys:** `{id}` only. Primary key: **`id`**. +- **Attributes:** + - `id` — UUID, required, primary key. + - `type` — text, required, restricted to `deposit`, `buy`, `sell`, `fee`. + - `amount` — numeric(18,4), required. Signed: negative for money leaving the + cash balance, positive for money arriving. + - `currency` — text, exactly 3 characters, required, default `USD`. + - `created_at` — timestamptz, required, defaults to now. + - `description` — text, optional, free-form human-readable explanation. + +#### MarketTrades +Individual executed trades on a market, from the user's own fills and from the +market simulator. This is the single source of truth for the current price: the +price of a market is the price of its most recent trade, never a column someone +writes directly. + +- **Candidate keys:** `{id}`. In principle `{market_id, executed_at}` looks + unique, but two trades can share a timestamp, so it is not a safe key. + Primary key: **`id`** (a plain auto-incrementing integer here rather than a + UUID, because this is the highest-volume entity set and it is only ever read + in timestamp order, never referenced by anything else). +- **Attributes:** + - `id` — integer, required, primary key, auto-generated. + - `executed_at` — timestamptz, required. + - `price` — numeric(18,6), required, must be > 0. + - `quantity` — numeric(20,6), required, must be > 0. + - `side` — text, optional, `buy` or `sell`. + - `source` — text, max 50, required, default `simulation`. Distinguishes a + simulated trade from a user's own fill (`user`). + +#### MarketCandles +OHLCV aggregates per market and timeframe — the data a price chart is drawn +from. Stored rather than computed on the fly because the point of the project is +a chart-driven interface, and re-aggregating the whole trade history for every +screen refresh does not scale. + +- **Candidate keys:** `{id}`, and `{market_id, timeframe, candle_time}` — a + market has exactly one candle per timeframe per time bucket. Primary key: + **`id`**; the composite is enforced as a uniqueness rule because it is the + real-world constraint and it is what prevents duplicate candles. +- **Attributes:** + - `id` — integer, required, primary key, auto-generated. + - `timeframe` — text, required, restricted to `1m`, `5m`, `1h`, `1d`. + - `open`, `high`, `low`, `close` — numeric(18,6), all required. + - `volume` — numeric(20,6), required. + - `candle_time` — timestamptz, required — the start of the bucket. + +#### Watchlists +A named list of assets a user wants to monitor. A separate entity set rather than +a flag on the relationship between users and assets, because a user may want +several lists ("long term", "watching today") and each needs its own name. + +- **Candidate keys:** `{id}`. `{user_id, name}` would also work if list names + are required to be unique per user; the model does not impose that, so it is + not listed as a candidate key. Primary key: **`id`**. +- **Attributes:** + - `id` — UUID, required, primary key. + - `name` — text, max 100, required. + - `created_at` — timestamptz, required, defaults to now. + +### Relationships + +#### QuotedOn — Cryptos (1) : Markets (N), total on Markets +Ties a market to the asset it trades. One asset can be quoted in many markets; +every market must have exactly one asset, hence total participation on the +`Markets` side. No attributes of its own. + +#### PlacedOn — Markets (1) : Orders (N), total on Orders +Records which market an order was placed on. Every order must name a market; +a market may have no orders yet. No attributes. + +#### Places — Users (1) : Orders (N), total on Orders +Records who placed an order. Every order belongs to exactly one user; a new user +has no orders. No attributes. + +#### Records — Users (1) : Transactions (N), total on Transactions +Attributes each ledger entry to a user. Every entry belongs to exactly one user. +No attributes. + +#### Settles — Orders (1) : Transactions (N), partial on both sides +Links a ledger entry to the order that caused it. Partial on the `Transactions` +side because deposits have no originating order, and partial on the `Orders` side +because an order that never executes never produces a ledger entry. This is why +the corresponding column is nullable in P2. No attributes. + +#### Fills — Markets (1) : MarketTrades (N), total on MarketTrades +Every executed trade happened on exactly one market. No attributes. + +#### Aggregates — Markets (1) : MarketCandles (N), total on MarketCandles +Every candle summarises trades of exactly one market. No attributes. + +#### Owns — Users (1) : Watchlists (N), total on Watchlists +Every watchlist belongs to exactly one user. No attributes. + +#### Holds — Users (M) : Cryptos (N), partial on both sides, **with attributes** +A user's position in an asset. M:N because one user holds many assets and one +asset is held by many users, and partial on both sides because a user may hold +nothing and an asset may be held by nobody. Modeled as a relationship rather +than an entity set because a position has no identity of its own — it is +entirely described by *which user*, *which asset*, and how much. + +- **Attributes:** + - `quantity` — numeric(20,4), required, must be ≥ 0. + - `avg_price` — numeric(18,6), required, ≥ 0, **derived** (dashed ellipse): + the weighted average of the prices at which the position was accumulated. + It is derivable from the buy history, and is stored anyway so that + unrealised P/L can be shown without replaying the whole ledger. + - `created_at` — timestamptz, required, defaults to now. + - `updated_at` — timestamptz, optional. + +#### Contains — Watchlists (M) : Cryptos (N), partial on both sides, **with attribute** +Which assets are on which watchlist. M:N: a list holds many assets, an asset +appears on many lists. Partial on both sides — an empty list is valid and an +asset need not be on any list. + +- **Attributes:** + - `added_at` — timestamptz, required, defaults to now. Recorded so a list can + be shown in the order the user built it. + +## Entity-Relationship Model History + +- **v01** — First complete version. Built from the entity notes in + [`ep-diagram.md`](ep-diagram.md) (the initial hand-written model), with three + changes made to that initial model while drawing it: + 1. `Markets` was promoted from an implied attribute of the asset to its own + entity set, so that prices, orders, trades and candles can all reference a + pair rather than an asset. + 2. `holdings` and `watchlist_items` were re-expressed as the M:N relationships + `Holds` and `Contains` with their own attributes, instead of entity sets + with foreign keys — the initial notes listed them as tables, which is a + relational concept that does not belong in a Chen ERD. + 3. `avg_price` was marked as a derived attribute rather than a plain one, to + make the denormalisation explicit rather than hidden. + +Reasoning for the AI-assisted part of this phase, and the full interaction log, +are on [ERModelAIUsage](ERModelAIUsage.md). Index: P1-ConceptualModel/ERModelAIUsage.md =================================================================== --- P1-ConceptualModel/ERModelAIUsage.md (revision d8ce4e224bde01e8f87558691226298db515617e) +++ P1-ConceptualModel/ERModelAIUsage.md (revision d8ce4e224bde01e8f87558691226298db515617e) @@ -0,0 +1,177 @@ +# Entity-Relationship Model AI Usage + +## Name of AI service/solution that was used + +**Claude Code** (Anthropic) + +- **URL:** https://claude.com/claude-code +- **Type of service/subscription:** Claude subscription. Session 1 used model + Claude Opus 4.7 (1M context); session 2 used Claude Opus 5 (1M context). + +## Final result + +### Diagram + +`ERModel_v01.xml` / `ERModel_v01.png`. + +**Declaration of how the diagram was produced.** The initial model is the +student's own: the entity and attribute list in [`ep-diagram.md`](ep-diagram.md), +written in Macedonian before any AI was involved. In session 2 the AI turned that +list into the TerraER diagram file, and while doing so proposed three changes to +the initial model, all three listed in the model history on +[ERModel](ERModel.md#entity-relationship-model-history): +promoting `Markets` to its own entity set, re-expressing `holdings` and +`watchlist_items` as M:N relationships with attributes rather than entity sets +with foreign keys, and marking `avg_price` as derived. + +The diagram was not drawn by hand in the TerraER GUI. It was generated +programmatically by constructing TerraER's own figure objects +(`EntidadeFigure`, `RelacionamentoFigure`, `AtributoFigure`, +`AtributoChaveFigure`, `AtributoDerivadoFigure` and the labelled line-connection +figures) and serialising them with TerraER's own +`DOMStorableInputOutputFormat` — the same writer the application uses when you +choose *Save*. The file is therefore a normal TerraER document: it was verified +by reading it back through TerraER's own reader and comparing the figure count +(144), and it opens and can be edited in TerraER 3.11 like any hand-drawn +diagram. Subsequent versions (`ERModel_v02.xml` onward) are edited by the student +in the GUI. + +### Model description + +See [ERModel](ERModel.md). + +## Summary of AI involvement + +Work on this project happened in two working sessions, several months apart. + +| | Session 1 | Session 2 | +|---|---|---| +| **When** | 2026-04-21 | 2026-08-06 / 2026-08-07 | +| **Model** | Claude Opus 4.7 (1M context) | Claude Opus 5 (1M context) | +| **Phases advanced** | P1, P2, P3 and the first working prototype | The ER diagram file, P4 documentation, bug fixes | +| **My starting material** | `ep-diagram.md`, `opis.md`, my existing Go backend and draft SQL | Everything from session 1, plus the phase rubric | + +In **session 1** I brought my own data model (`ep-diagram.md`, written in +Macedonian before any AI was involved) and my own draft schema and Go backend. I +used the AI to review them, and it found real errors in my SQL that I had missed +— most seriously that I had declared `crypto_id` as a foreign key to two +different tables at once, in three separate tables. I decided the corrections to +adopt, chose to go solo, chose a CLI prototype over an HTTP one, and chose +English for the documentation. The output of that session was the corrected +schema, the sample-data script, the use-case model and the working prototype. + +In **session 2** I came back to produce the deliverable I was still missing — the +TerraER diagram file itself — and to finish the P4 documentation. I also asked +for a review pass over the database and Go code, which turned up three further +bugs (see [PrototypeImplementationAIUsage](../P4-Prototype/PrototypeImplementationAIUsage.md)). + +Below is the log, one entry per exchange. My prompts are quoted as **excerpts**: +the wording is my own, unaltered, but I have left out scheduling remarks and +other working chatter that says nothing about the model or the code. Typos are +kept as they were. The *Intent* line above each prompt is my own note on what I +was trying to achieve. AI responses are summarised rather than quoted in full, +because several ran to many pages of code and file edits. The complete +unabridged transcript is in my Claude Code session history and can be produced +on request. + +## Entire AI usage log + +--- + +### Session 1 — 2026-04-21 + +**Intent:** hand the AI the whole project and the course rubric, and have it +audit my existing model and code against the phase requirements before I commit +to anything. + +**Prompt (student, excerpt):** +> This is my project for my exam Database, go to the docs folder and README.md there you will find all of the documentation, afterwards take a look at the whole project. Delete everything you want add everything you want just make it work and make it fill in or to follow all of the needed instructions. Ask me anything, also tell me what do I need to do + +**Response (AI, summarised):** +- Read `docs/opis.md`, `docs/ep-diagram.md`, `docs/dbdiagram.md`, `server/db/db.sql`, `server/db/schema.sql`, all Go sources. +- Flagged bugs in the initial schema: + - `holdings.crypto_id` declared as a foreign key to both `users(id)` and `crypto(id)`; should be a separate `user_id` column. + - Same mistake in `orders` and `transactions`. + - `market_candles` referenced a non-existent `markets` table. + - `main.go` dropped and recreated all tables on every startup, wiping data. +- Proposed a single authoritative schema, to be placed in `server/db/schema_creation.sql`, based on `docs/ep-diagram.md` and `docs/dbdiagram.md` with the above issues fixed. +- Asked the student for decisions: team composition, prototype shape (CLI vs HTTP), whether to keep `available_balance`, `invested_balance`, `secret_question`, `secret_answer`, which use cases to implement, language of documentation. + +**Intent:** I had just pasted the course rubric into `README.md` and removed the +half-finished frontend, so that the AI would plan against the actual phase +requirements and against a backend-only prototype. + +**Prompt (student, excerpt):** +> Read it now, just filled it in, also deleted the frontend we don' need that + +**Response (AI, summarised):** +- Re-read `docs/README.md`, which now contained the course phase rubric (P0–P9). +- Explained the constraints each phase places on AI usage (P0 forbids AI; P1–P4 allow AI only to improve the student's own initial model and require an AIUsage log). +- Listed the deliverables per phase and asked the remaining questions. + +--- + +### Session 2 — 2026-08-06 / 2026-08-07 + +**Intent:** re-read the rubric from scratch after the gap, reduce it to a +checklist of what each phase actually has to produce, confirm TerraER runs on +this machine. + +**Prompt (student, excerpt):** +> We will start from the begining in some ways, please read first docs/insturctions.md +> The goal is to finish with milestone 0 so I can publish it […] +> Read the Instuctions.md like I said and delete everything that you think we don't need +> and for each phrase tell me what do I need to submit and how to do it. and can you also +> do the thing with TerraER3.11.jar? + +**Response (AI, summarised):** +- Read the phase rubric and condensed `Instructions.md` to a per-phase checklist + of deliverables, keeping every requirement and every load-bearing filename. +- Confirmed TerraER 3.11 runs on the installed OpenJDK 21 and launched it. +- Listed, per phase, what has to be submitted and how; flagged that P0's + deliverables are wiki pages, that the EPRMS proposal is a prerequisite. +- Flagged `image.png` (a TradingView screenshot) as material the project has no + licence to publish. + +**Intent:** produce the artefacts still missing for P1–P4 — above all the TerraER +diagram — while keeping P0 for myself, since AI use is forbidden there. + +**Prompt (student, excerpt):** +> […] do all of the other Phases till m0. +> opis.md It's p0 so I will take care of that. Delete anything that we don't need, +> make all of the phases and terra diagram if you can, and delete anything +> that we don't need and make a documentation about how to start it. + +**Intent:** ask for a review pass over the schema and the Go code rather than +only documentation, on the grounds that a prototype I have to defend in person +should not have known defects in it. + +**Prompt (student, excerpt, follow-up):** +> Also fix some database things or golang things if you think we can do it better, + +**Response (AI, summarised) — the part relevant to P1:** +- Read `ep-diagram.md` (the student's own initial model) and the existing + `schema_creation.sql`. +- Reverse-engineered TerraER's file format from the distributed jar to learn the + element names it stores figures under (`ent`, `rel`, `atr`, `atrchave`, + `atrderivado`, `llabelUm`, `llabelMuitos`, `llabelDoubleUm`, + `llabelDoubleMuitos`, …). +- Generated `ERModel_v01.xml` and `ERModel_v01.png` as described above, in Chen + notation: 8 entity sets, 10 relationships, 57 attributes, cardinality labels + on every relationship line and double lines for total participation. +- Proposed the three changes to the initial model recorded in the model history. +- Rewrote [ERModel](ERModel.md) with the per-entity documentation, candidate-key + justifications and attribute types the phase template requires. + +--- + +> **Student action required.** Two things, in this order: +> +> 1. Open `ERModel_v01.xml` in TerraER, read the whole diagram, and change what +> you disagree with. Save the result as `ERModel_v02.xml` with a matching PNG +> and add a history line. The phase rules require that the model be yours; +> the generated v01 is a starting point to review and take over, not an +> answer to submit unread. +> 2. Verify that this log matches your recollection and append the full text of +> any further prompts. The complete transcript is in your Claude Code session +> history. Index: P1-ConceptualModel/ERModel_v01.xml =================================================================== --- P1-ConceptualModel/ERModel_v01.xml (revision d8ce4e224bde01e8f87558691226298db515617e) +++ P1-ConceptualModel/ERModel_v01.xml (revision d8ce4e224bde01e8f87558691226298db515617e) @@ -0,0 +1,1 @@ +CryptosMarketsMarketTradesMarketCandlesOrdersTransactionsUsersWatchlistsQuotedOnFillsAggregatesPlacedOnSettlesRecordsPlacesHoldsOwnsContains

3

3

3

3

3

3

3

created_at

name

symbol

truetrueid

created_at

is_active

quote_currency

truetrueid

truetrueid

executed_at

price

quantity

side

source

truetrueid

timeframe

open

high

low

close

volume

candle_time

truetrueid

side

type

status

quantity

price

placed_at

executed_at

truetrueid

type

amount

currency

created_at

description

truetrueid

username

email

full_name

password_hash

available_balance

invested_balance

created_at

updated_at

created_at

name

truetrueid

quantity

5avg_price

created_at

updated_at

added_at

Index: P1-ConceptualModel/ep-diagram.md =================================================================== --- P1-ConceptualModel/ep-diagram.md (revision d8ce4e224bde01e8f87558691226298db515617e) +++ P1-ConceptualModel/ep-diagram.md (revision d8ce4e224bde01e8f87558691226298db515617e) @@ -0,0 +1,197 @@ +Ентитети + +User – ентитет кој чува информации за корисниците на платформата + +id (uuid) + +username (varchar(50), not null, unique) + +email (varchar(255), not null, unique) + +password_hash (varchar(255), not null) + +full_name (varchar(200)) + +created_at (timestamptz) + +updated_at (timestamptz) + + +Crypto – ентитет кој ги чува податоците за криптовалутите со кои се тргува + +id (uuid) + +symbol (varchar(20), not null, unique) + +name (varchar(255)) + +created_at (timestamptz) + + + +Market – ентитет кој ги дефинира пазарите (парови криптовалути и валути за котација(BTCUSDT, ADAUSDT, ADABTC)) + +id (uuid) + +crypto_id (uuid, not null, FK → Crypto.id) + +quote_currency (char(3), not null) ADA, USDT, BTC, USDT + +is_active (boolean) + +created_at (timestamptz) + + + +Holding – ентитет кој ги чува позициите на корисниците во криптовалути + +id (uuid) + +user_id (uuid, not null, FK → User.id) + +crypto_id (uuid, not null, FK → Crypto.id) + +quantity (numeric(20,4), not null) + +avg_price (numeric(18,6)) + +created_at (timestamptz) + +updated_at (timestamptz) + + + +Order – ентитет кој ги чува нарачките за купување/продавање + +id (uuid) + +user_id (uuid, not null, FK → User.id) + +market_id (uuid, not null, FK → Market.id) + +side (varchar(4), not null) — типично “buy” или “sell” + +type (varchar(20), not null) — тип на нарачка, пример “limit”, “market” + +status (varchar(20), not null) — статус на нарачка (open, executed, cancelled) + +quantity (numeric(20,4), not null) + +price (numeric(18,6)) + +placed_at (timestamptz) + +executed_at (timestamptz) + + + +Transaction – ентитет кој ја следи финансиската активност на корисниците (депозити, купувања, продавања, провизии) + +id (uuid) + +user_id (uuid, not null, FK → User.id) + +type (varchar(50), not null) — пример: “deposit”, “buy”, “sell”, “fee” + +amount (numeric(18,4), not null) + +currency (char(3), not null) + +related_order (uuid, FK → Order.id) + +created_at (timestamptz) + +description (text) + + + +Market_Trade – ентитет кој ги евидентира извршените пазарни зделки кои ја формираат цената + +id (bigserial) + +market_id (uuid, not null, FK → Market.id) + +executed_at (timestamptz, not null) + +price (numeric(18,6), not null) + +quantity (numeric(20,6), not null) + +side (varchar(4)) + +source (varchar(50)) + +Market_Candle – ентитет кој ги агрегира податоците за цените и волуменот во временски интервали (целови) + +id (bigserial) + +market_id (uuid, not null, FK → Market.id) + +timeframe (varchar(5), not null) — пример: “1m”, “5m”, “1h” + +open (numeric(18,6), not null) + +high (numeric(18,6), not null) + +low (numeric(18,6), not null) + +close (numeric(18,6), not null) + +volume (numeric(20,6), not null) + +candle_time (timestamptz, not null) + +Watchlist – ентитет кој ги чува листите за следење на корисниците + +id (uuid) + +user_id (uuid, not null, FK → User.id) + +name (varchar(100)) + +created_at (timestamptz) + +Watchlist_Item – ентитет кој ги чува криптовалутите кои се ставени во некоја листа за следење + +id (uuid) + +watchlist_id (uuid, not null, FK → Watchlist.id) + +crypto_id (uuid, not null, FK → Crypto.id) + +added_at (timestamptz) + +Релации + +User – Holding (1:N) +Еден корисник може да има повеќе позиции во различни криптовалути. + +Crypto – Holding (1:N) +Една криптовалута може да се држи од повеќе корисници. + +User – Order (1:N) +Еден корисник може да има повеќе нарачки. + +Market – Order (1:N) +Еден пазар има повеќе нарачки. + +User – Transaction (1:N) +Еден корисник има повеќе трансакции. + +Order – Transaction (0..1 : N) +Трансакцијата може да биде поврзана со една нарачка (пример купување/продажба). + +Market – Market_Trade (1:N) +Еден пазар има многу извршени зделки. + +Market – Market_Candle (1:N) +Еден пазар има многу временски агрегирани податоци. + +User – Watchlist (1:N) +Еден корисник може да има повеќе листи за следење. + +Watchlist – Watchlist_Item (1:N) +Една листа може да содржи повеќе криптовалути. + +Crypto – Watchlist_Item (1:N) +Една криптовалута може да биде во повеќе листи за следење.