Database
 sql >> Teknologi Basis Data >  >> RDS >> Database

Pemodelan Database untuk Pencatatan Penjualan. Bagian 1

Menyimpan data penjualan dengan benar dan kemudian menggabungkannya dapat menghasilkan model prediktif dengan tingkat akurasi yang tinggi. Dalam artikel ini dan beberapa artikel berikutnya, kita akan menganalisis desain database untuk mencatat penjualan.

Semua orang hidup dengan menjual sesuatu.

Robert Louis Stevenson

Di dunia sekarang ini, menjual produk ada di mana-mana. Dan tenaga penjualan yang memiliki akses ke alat canggih yang memanfaatkan data historis untuk menganalisis tren dan memungkinkan perusahaan untuk menyesuaikan strategi bisnis yang sesuai memiliki keunggulan dibandingkan pesaing mereka. Ada banyak parameter yang dapat memengaruhi hasil perusahaan:situasi ekonomi global saat ini, lokasi klien, usia, materi dan status perkawinan, serta riwayat kontak atau penjualan sebelumnya kepada klien.

Kita akan mulai dengan contoh yang sangat sederhana:model database untuk penjualan di kedai kopi . Dalam artikel berikutnya, kami akan memperluas model untuk menjual produk di cabang lain.

Model Penjualan

Dalam artikel ini, kami hanya akan menganalisis sebagian model yang berisi data penjualan dengan bagian lain yang hilang.

Kami masih memiliki koneksi ke tabel yang hilang dan kami akan melihat model sebagai kotak hitam dengan asumsi bahwa yang berikut ini benar untuk tabel sale :

  • user_has_role_id lihat id di user_has_role (seperti yang disajikan dalam artikel saya sebelumnya di bagian “Komponen waktu ditambahkan”) dan menyimpan informasi tentang pengguna yang membuat catatan penjualan



Model ini memungkinkan kita untuk membuat catatan penjualan dengan beberapa item. Setiap item terkait dengan produk dari katalog kami. Momen saat kita menghasilkan penjualan bisa berbeda dengan saat penjualan dibayar. Misalnya, untuk secangkir kopi momen ini akan berbeda dalam hitungan menit atau jam. Jika toko kami menjual perangkat telekomunikasi, perbedaannya bisa beberapa hari, bahkan mungkin berbulan-bulan.

Tabel

Mari kita lihat definisi tabel dan jelaskan tujuan dan penggunaan atribut.

Tabel terpenting dalam model adalah product . Ini digunakan untuk menyimpan detail tentang produk yang akan kami tawarkan kepada klien kami. Produk biasanya dikirim ke klien dan dibayar sekali, biasanya pada waktu pengiriman. Selain itu, produk biasanya berupa objek fisik seperti mobil, telepon, paket gula, atau cangkir kopi.

Kita akan berbicara tentang menjual barang (jasa) non-fisik di artikel berikutnya.

Atribut dalam product tabelnya adalah:

  • name – nama produk dalam sistem
  • price_per_unit – biaya produk per unit (mis., 1 cangkir kopi berharga 1,8 Euro, 1 mobil berharga 17.500 Euro, 1 kg beras berharga 2 Euro)
  • basic_unit – unit dasar saat kami menjual produk (mis., satuan, kg, liter)
  • tax_percentage – persen dari harga_per_unit yang akan dibebankan sebagai pajak. Kita harus berasumsi bahwa persentase pajak tidak akan sama untuk semua produk
  • limited – kolom ini disetel ke True jika kami memiliki stok dalam jumlah terbatas dan False jika tidak (misalnya, kami dapat memesan jumlah berapa pun yang kami butuhkan untuk toko kami dari distributor)
  • in_stock – if limited=True atribut ini menunjukkan berapa banyak yang kami miliki untuk dijual
  • active_for_sale – jika atribut ini Salah maka saat ini kami tidak menawarkan produk tersebut untuk dijual, jika tidak, kami dapat menawarkannya kepada klien

Kami dapat memperoleh daftar produk yang dapat kami tawarkan kepada klien dengan pertanyaan berikut:

SELECT product.id, product.price_per_unit, 
       product.basic_unit, product.limited, product.in_stock
FROM product
WHERE product.active_for_sale = True
AND (product.limited = False OR
      (product.limited = True and product.in_stock > 0))

Tabel sale_status hanyalah kamus sederhana yang berisi semua status yang dapat dimiliki penjualan dalam sistem (mis., “tanda terima dikeluarkan”, “tanda terima dibayar”).

Tabel sale adalah tabel terpenting kedua dalam model ini. Sejauh ini, tabel ini tidak memiliki hubungan dengan klien yang kami jual produk karena, dalam contoh kedai kopi kami, kami tidak perlu mengetahui informasi tersebut. Pada bagian 2, model akan diperluas untuk mencakup kasus-kasus seperti itu.

Atribut pada tabel dan artinya adalah:

  • time_created – waktu ketika catatan penjualan dibuat dalam sistem (misalnya, waktu otomatis catatan itu dibuat ketika kami membuat penjualan untuk kopi di kedai kopi kami atau waktu yang ditambahkan secara manual jika kami menginginkannya)
  • time_paid – umumnya kami dapat mengharapkan bahwa beberapa penjualan akan dibayar dalam beberapa hari atau bahkan sebulan setelah pembuatan (misalnya, jika kami mengirimkan perangkat lunak dan membuat tanda terima, kami dapat menunggu hingga 90 hari untuk menerima pembayaran di beberapa negara, jika semuanya berjalan lancar hukum)
  • sale_amount – jumlah awal yang dimaksudkan untuk dibebankan ke klien
  • sale_amount_paid – jumlah yang sebenarnya dibayar klien. Itu bisa nol karena saat ini kami membuat tanda terima, kami tidak selalu memiliki informasi ini
  • tax_amount – jumlah semua jumlah pajak untuk item pada tanda terima tersebut
  • sale_status_id – referensi ke sale_status meja
  • user_has_role_id – referensi ke pengguna dan perannya saat dia memasukkan tanda terima ke sistem

Kita bisa mendapatkan jumlah yang dikeluarkan dan dibayar (sesuai dengan time_created) dalam jangka waktu tertentu dengan query seperti ini:

SELECT SUM(sale.sale_amount) AS amount_issued,
       SUM(sale.sale_amount_paid) AS amount_paid 
FROM sale
WHERE sale.time_created >= @start_time 
AND sale.time_created <= @end_time;

Untuk mendapatkan jumlah pembayaran yang tepat dalam jangka waktu tertentu, kita harus menggunakan kueri seperti ini:

SELECT SUM(sale.sale_amount_paid) AS amount_paid 
FROM sale
WHERE sale.time_paid >= @start_time 
AND sale.time_paid <= @end_time;

Kueri di bawah ini akan menghitung jumlah yang diterbitkan dan dibayar dalam jangka waktu tertentu dengan tanggal penerbitan dan tanggal pembayaran diperiksa secara terpisah:

SELECT 
SUM(CASE WHEN sale.time_created >= @start_time 
    AND sale.time_created <= @end_time 
    THEN sale.sale_amount END) AS amount_issued,
SUM(CASE WHEN sale.time_paid >= @start_time 
    AND sale.time_paid <= @end_time 
    THEN sale.sale_amount_paid END) AS amount_paid 
FROM sale

Dalam semua contoh @start_time dan @end_time adalah variabel yang berisi waktu mulai dan waktu akhir periode yang ingin kita periksa SUM yang dikeluarkan dan dibayar.

Tabel sale_item menghubungkan produk dan penjualan. Tentu saja, kita harus berasumsi bahwa kita akan memiliki banyak item pada satu tanda terima sehingga kita membutuhkan tabel ini untuk memiliki hubungan banyak-ke-banyak.

Atribut dan artinya adalah:

  • quantity_sold – jumlah produk yang dijual dan dibebankan pada penjualan/penerimaan tersebut (mis., 3 kopi)
  • price_per_unit – nilai yang sama dengan product.price_per_unit pada saat penjualan dibuat. Kami harus menyimpannya karena price_per_unit di product tabel dapat berubah seiring waktu
  • price – produk dari quantity_sold dan price_per_unit; redundansi kecil yang membantu kami menghindari penghitungan ini dalam kueri. Umumnya, jumlah semua harga barang milik obral yang sama harus sama dengan sale.sale_amount
  • tax_amount – jumlah pajak untuk barang tersebut pada tanda terima
  • sale_id – id penjualan yang dimiliki barang ini
  • product_id – id produk yang terkait dengan item ini

Kami sekarang dapat dengan mudah membuat laporan sederhana, berapa banyak produk/jasa yang kami jual dalam periode dan berapa harganya.

SELECT product.name, SUM(sale_item.quantity_sold) AS quantity, 
       SUM(sale_item.price) AS price
FROM sale, sale_item, product
WHERE sale.id = sale_item.sale_id
AND sale_item.product_id = product.id
AND sale.time_created >= @start_time 
AND sale.time_created <= @end_time
GROUP BY product.id


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Penggunaan Utama sys.dm_os_wait_stats

  2. Peningkatan potensial untuk ASPSstate

  3. Ketika BERBEDA <> GROUP BY

  4. Model Data Catur 3D Star Trek

  5. Pencarian Pola Skema ke Asosiasi Kelas Data