A. 關於sql多類別匯總取最大值的實現
銷售明細按站名、各大類中的銷售收入最高的商品進行匯總。想了半天 可以用如下SQL實現：
select a.便利店名稱,a.商品品類描述,round(a.銷售收入max,2) as 收入,b.商品名稱 from
(
select 便利店名稱, 商品品類描述, max(銷售收入base) as 銷售收入max from
(
SELECT 便利店名稱, 商品品類描述, 商品名稱, sum(銷售收入) AS 銷售收入base FROM usmile GROUP BY 便利店名稱, 商品品類描述, 商品名稱 HAVING sum(銷售收入)>0
) base
GROUP BY 便利店名稱, 商品品類描述
) a,
(
select 便利店名稱, 商品名稱, max(銷售收入base) as 銷售收入max from
(
SELECT 便利店名稱, 商品品類描述, 商品名稱, sum(銷售收入) AS 銷售收入base FROM usmile GROUP BY 便利店名稱, 商品品類描述, 商品名稱 HAVING sum(銷售收入)>0
) base
GROUP BY 便利店名稱, 商品名稱
) b
where a.便利店名稱=b.便利店名稱 and a.銷售收入max=b.銷售收入max
B. 數據分析需要掌握哪些知識
數據分析定義
數據分析是指用適當的統計分析方法對收集來的大量數據進行分析，提取有用信息和形成結論而對數據加以詳細研究和概括總結的過程。這一過程也是質量管理體系的支持過程。在實用中，數據分析可幫助人們作出判斷，以便採取適當行動。是有組織有目的地收集數據、分析數據，使之成為信息的過程。
數據分析分類
數據分析劃分為描述性統計分析、探索性數據分析以及驗證性數據分析；其中，探索性數據分析側重於在數據之中發現新的特徵，而驗證性數據分析則側重於已有假設的證實或證偽。
數據分析常用方法
1、PEST分析：
是利用環境掃描分析總體環境中的政治（Political）、經濟（Economic）、社會（Social）與科技（Technological）等四種因素的一種模型。這也是在作市場研究時，外部分析的一部分，能給予公司一個針對總體環境中不同因素的概述。這個策略工具也能有效的了解市場的成長或衰退、企業所處的情況、潛力與營運方向。一般用於宏觀分析。
2、SWOT分析：
又稱優劣分析法或道斯矩陣，是一種企業競爭態勢分析方法，是市場營銷的基礎分析方法之一，通過評價自身的優勢（Strengths）、劣勢（Weaknesses）、外部競爭上的機會（Opportunities）和威脅（Threats），用以在制定發展戰略前對自身進行深入全面的分析以及競爭優勢的定位。而此方法是Albert Humphrey所提。
3、5W2H分析：
用五個以W開頭的英語單詞和兩個以H開頭的英語單詞進行設問，發現解決問題的線索，尋找發明思路，進行設計構思，從而搞出新的發明項目具體：
（1）WHAT——是什麼？目的是什麼？做什麼工作？
（2）WHY——為什麼要做？可不可以不做？有沒有替代方案？
（3）WHO——誰？由誰來做？
（4）WHEN——何時？什麼時間做？什麼時機最適宜？
（5）WHERE——何處？在哪裡做？
（6）HOW ——怎麼做？如何提高效率？如何實施？方法是什麼？
（7）HOW MUCH——多少？做到什麼程度？數量如何？質量水平如何？費用產出如何？
4、7C羅盤模型：
7C模型包括
（C1）企業很重要。也就是說，Competitor：競爭對手，Organization：執行市場營銷或是經營管理的組織，Stakeholder：利益相關者也應該被考慮進來。
（C2）商品在拉丁語中是共同方便共同幸福的意思，是從消費者的角度考慮問題。這也和從消費者開始考慮問題的整合營銷傳播是一致的，能體現出與消費者相互作用進而開發出值得信賴的商品或服務的一種哲學。經過完整步驟創造出的商品可以稱之為商品化。
（C3）成本不僅有價格的意思，還有生產成本、銷售成本、社會成本等很多方面。
（C4）流通渠道表達商品在流動的含義。創造出一個進貨商、製造商、物流和消費者共生的商業模式。作為流通渠道來說，網路銷售也能算在內。
（C5）交流
（C6）消費者
N = 需求（Needs）：生活必需品，像水、衣服、鞋。
W = 想法（Wants）：想得到的東西，像運動飲料、旅遊鞋。
S = 安全（Security）：安全性，像核電、車、食品等物品的安全。
E = 教育（Ecation）：對消費者進行教育，為了能夠讓消費者也和企業一樣對商品非常了解，企業應該提供給消費者相應的知識信息。
（C7）環境
N = 國內和國際：國內的政治、法律和倫理環境及國際環境，國際關系。
W = 天氣：氣象、自然環境，重大災害時經營環境會放生變化，適應自然的經營活動是必要的。像便利店或是部分超市就正在實行。
S = 社會和文化：網路時代的社會、福利及文化環境理所當然應該成為考慮因素。
E = 經濟：經濟環境是對經營影響最大的，以此理所當然應該成為考慮因素。7C羅盤模型是一個合作市場營銷的工具。
5、海盜指標法AARRR:是互聯網常用的「用戶增長模型」，黑客增長模型：
Acquisition：獲取用戶
Activation：提高活躍度
Retention：提高留存率
Revenue：獲取收入
Refer：自傳播
數據分析常用工具
日常數據分析用的最多的還是辦公軟體尤其excel、word、ppt，數據存儲處理可能用到一些資料庫結合access用，另外目前一般公司小型關系資料庫用mysql的還是比較多免費、輕量級，還有較多的也在用pg。
其次分析師是用一些專業的分析軟體spss，sas，自助分析用的BI軟體平台如：finebi、tableau等。
finebi
其實想強調的是分析師40%-60%的時間可能會花在數據的獲取、處理和准備上，所以最好能會點sql，個人覺得對於分析師與其去了解資料庫，不如好好去學下sql，因為sql是標准化的數據查詢語言，所有的關系型資料庫包括一些開源的資料庫甚至各公司內部的數據平台都對它有良好的支持。最後對於第三方的一些數據收集或者一些跨平台的數據處理，包括一些分析可以用finebi。
數據分析流程
有了 這些基礎的理論和分析方法後，接下來具體的分析流程可參考：
1.提出問題（需求） 2.結論/假設 3.數據准備 4.數據分析 5.報告生成 結論驗證。
我們按照如上的分析步驟來個示例：
XX產品首銷，哪些用戶最有可能來購買？應該給哪些用戶進行營銷？
第一步首先是提出了問題，有了需求。
第二步分析問題，提出方案，這一步非常重要，正如上面提到的第二三類的數據分析本身就是一個假設檢驗的過程，如果這一步不能很好的假設，後續的檢驗也就無從談起。主要需要思考下從哪些方面來分析這個問題。
可以從三個方面：（PS：這里對於一些常規的屬性比如：性別、年齡、地區分布了這些基本，老大早已心中有數，就不再看了）
1.曾經購買過跟XX產品相似產品的用戶，且當前使用機型是XX產品上一或幾代產品，有換機意願需求的。
2.用戶的關注程度用戶是否瀏覽了新品產品站，是否搜索過新品相關的信息，是否參加了新品的活動。
3.用戶的消費能力歷史消費金額、歷史購機數量、本年度購機金額、本年度購機數量、最近一次購機時間及金額等。
第三步准備數據：
創建分析表，搜集數據 這一步基本是最花時間的，這時候就是考量你的數據平台、數據倉庫的時候了，倉庫集成的好，平台易用的話時間應該不用太長。
第四步數據分析：筆者是把數據導入到finebi進行分析的，也可以用python，其實用excel也非常好，只是筆者對excel的有些處理不是很擅長。
第五步就是圖表呈現，報告的表達了，最後我們驗證得到的一個結論就是：購買過同類產品，關注度越高，復購周期越近的用戶越最容易再次復購。
註：想要獲取33個好用數據分析工具，可以私聊回復我「工具」獲得！
C. sql語句，多表聯查問題，求sum值
需要的第一個sql
selecta.pname,b.stockfromprocta,proctStorebwherea.pid=b.pidandb.stock>0
需要的第二個sql
selecta.pid,max(a.pname),sum(b.stock)fromprocta,proctStorebwherea.pid=b.pidgroupbya.pid
D. 便利店行業如何通過線下大數據實現快速精準拓店
燒烤攤、麻辣燙、大排檔被定義為中國版的深夜食堂，然而隨著寫字樓的燈火蔓延，便利店也成為了年輕人的深夜棲息地。有別於傳統雜貨鋪，90年代傳入中國的現代便利店呈現規模化和統一管理，行業規模發展迅猛，2019年中國便利店行業實現銷售額2556億元。
隨著行業規模的高速發展，一線城市消費市場開始飽和，外資連鎖便利店也開始走向下沉市場，二三線城市的便利店競爭將會日漸激烈。大數據時代如何利用數據及人工智慧賦能於線下品牌連鎖將是實體零售從業者面臨的難題之一，本文將從便利店現狀及大數據如何賦能的角度，為從業者們提供思考方向。
便利店誕生於美國，因其小型化、高毛利、便利性、精簡SKU等特性，逐漸成為一種新的零售業態。90年代中期，便利店概念開始進入中國。2019年中國便利店門店總數達到13.2萬家，較上年增加了1萬余家。
從單個便利店企業擴張表現來看，石油系便利店（易捷、昆侖好客）在門店擴張上表現搶眼，其次是本土品牌美宜佳和天福，外資便利店則主要分布與一二線城市。
但觀察近年來外資便利店在中國的城市版圖布局：從去年底開始，7-ELEVEn先後在福州、長沙、西安、合肥開設首店，另一家日資便利店羅森行動更為迅速，已於去年在長沙、沈陽、泰州等城市先後開出首店。
對於全國商業格局而言，此次外資便利店的布局，被認為是近年來「市場下沉」的又一個印證，同時也意味著下沉市場連鎖便利店的競爭更加激烈。
隨著 科技 和城市的發展，一線城市的消費市場逐漸飽和，而在二三線城市，連鎖品牌便利店存在著拓店難、無法融入當地市場的問題。
傳統夫妻店投入資本小、受地理位置限制小，經營的可控性比較強，且選址往往在居住地附近。而對於連鎖便利店來說，店鋪選址除了需要考慮周邊的消費市場，更要考慮采購與進貨問題（小街小巷無法統一配貨，增大成本）、客群畫像等。
這時候，傳統的選址方法是通過人工到線下多個目標位置點進行觀察測算，人力和時間成本非常高，且客群畫像無法精準。試想一下如何能夠短時間內通過一個人的外表確定其消費能力呢？
但在大數據時代，這些信息都可以高速便捷獲取。
數位是國內最早一批涉足線下大數據智能應用的大數據 科技 公司，深耕線下人場大數據5年，能夠實時洞察人和場的智能動態數據，高效為企業提供用戶分析、客群畫像和周邊客流。數位對線下零售（如連鎖便利店）有三大價值：
1 快速拓店選址： 數位擁有全維度動態的人場大數據，自有海量數據標簽，覆蓋200+城市，8000萬POI庫，能夠為企業提供批量化的線下人場數據，利於連鎖品牌的規模化拓展。
當品牌進入一個新城市，能夠快速判斷城市不同區域位置信息，幫助品牌根據自己的定位（如社區型/商圈型等）快速有效佔領消費市場，並運用人工智慧演算法對周邊客群、人流方向進行洞察分析，從而利於品牌在商品定位上更趨近於消費者心理。
2 老店數據實時監控： 對於品牌連鎖店來說，許多經營多年的老店面臨著周圍市政或消費環境的變動，如新商場建立、老建築拆遷等。
當老店營業額產生波動時，傳統檢驗方式是線下踩點考證，但客流的變動易觀察，客群畫像的變動卻無法短時間進行判別。數位大數據則能夠第一時間反饋老店周邊市場與客群畫像的變動，及時做出經營方向和商品選擇上的調整。
3 競對商鋪比較： 入駐前，同一片區域內原有的競對商鋪的數量及客流畫像能夠給品牌帶來極高參考價值；開店後，區域內出現新的競對商鋪也是影響店鋪營業額的重要原因。數位線下大數據能夠幫助品牌實時觀察周邊競對環境，分析優劣勢，及時做出經營上的調整；
4 經營模型沉澱： 為什麼同樣開在市中心的兩家店營業額卻大相徑庭？開在醫院對面與開在學校對面哪一家營業額更佳？如何根據人群移動規律調整商品陳列？這些傳統人力難以系統統計的數據，利用大數據可以快速幫助門店沉澱一套方法論，形成品牌自有的經營模型，對品牌進一步布局和拓店有重大參考價值，有效節省新店拓店成本。
品牌便利店"下沉"二三線城市，是城市發展的必然，也極有可能是一次再定義當地消費趨勢的機會。在這樣的前提下，品牌佔領市場的時間顯得尤為寶貴。
零售行業已從「貨——場——人」轉變為大數據時代的「人——貨——場」，提前洞察客流及客群信息，加上當地場景數據，最後再結合品牌本身特性才能夠快速打入當地消費市場，搶占消費份額。
連鎖品牌入駐新城市時投入成本高，傳統的選址方式已不足以支撐品牌的快速拓展，批量化的人場大數據才是現代品牌快速拓展版圖的「秘密武器」。數位基於5年高精度技術的沉澱，擁有全國最大的識別資料庫，在品牌選址、客群洞察及市場營銷中，都能夠為連鎖品牌帶來強有力的決策支持。
E. 怎樣使用Access建立便利店的資料庫
例:
表1:類別
欄位名:煙酒類,百貨,稱重
表2:品種
欄位名,類別,條碼,進價,售價,庫存......
表3:銷售記錄
欄位名:流水號,名稱,售價,時間,總價......
等等,根據自己的要求和能力進行設計.
F. 求思訊便利店8和v8的安裝教程
先裝sql資料庫 裝好後安裝思迅server程序 在裝setup程序 有升級包的話裝下升級包
G. 超市便利店的SQL表設計
一個表就可以解決問題：
欄位：
ID，商品編號、商品名稱、商品規格、商品進貨價、商品出售價、進貨數量、庫存數量、出售數量，這些欄位是必須的，其他看你的需要添加即可。
H. 請問收銀軟體為什麼要使用SQL2000、SQL2005
sql2000 ？[捂臉][捂臉]我只知道我以前開傳奇，架設客服端用的SQL2000。管理挺方便的，[捂臉][捂臉]
都沒說到點上，這類軟體大多都是10年之前，甚至更早，那個時候這類軟體資料庫基本是sql2000，晚一點用2005，開發基本是delphi,powerbuider,vs.net
十年前或者更久遠的系統，只有是運行在Windows系統下的收銀軟體，90%甚至更高的比例，運行使用的資料庫都是採用SQL2000。即使，SQL2005發布後，很多零售系統使用的系統的資料庫也不會立馬升級。SQL2000因為簡單易用、穩定安全（基於WinNT 2000系統），所以，大部分軟體開發者都會選擇使用SQL2000作為默認資料庫。
即使現在，也有一部分系統還是運行sql2000的資料庫，只要能滿足系統運行需求，我們也不必糾結為啥都2020年了，怎麼還有人使用SQL2000資料庫！
首先要排除大型和特大超市他們的系統都是定製的基本都在幾十萬以上。其次小型超市和便利店使用的是因為，第一 這些資料庫目前是免費的。 第二收銀系統功能單一要求配置不高。硬體的費用低。
本地單機資料庫sqlexpress夠了免費簡單穩定，不需要很高的性能，伺服器的資料庫各種都有
[捂臉]我們用的還是foxbase，，，開始是dos下的進銷存，裝在win98上用，後來主板壞了，沒辦法找，就升級了一下，支持xp，還是fb資料庫，一直用到現在，穩定性沒問題
去年我們才把全公司幾十台電腦從XP升級到WIN7[捂臉][捂臉][捂臉]，什麼系統無所謂，關鍵是兼容應用軟體，以及穩定。電腦兩三年都會換一批，硬體更新換代沒多少錢，但是遷移系統是成本非常高的。
那是資料庫用的吧。不然怎麼存儲數據，而且SQL2000或2005存儲的容量大，安全系數也高。
因為收銀機配置沒那麼高，很多還是xp系統內存只有1-2G，WIN7的機器，內存2-4G，sql2000占內存小，你試sql2008，內存馬上滿了
歷史 原因。要是現在新開發的收銀軟體估計都是用MySQL和PostgreSQL。
I. 資料庫課程設計實例
資料庫課程設計
題目：小型超市管理系統
1、項目計劃
1.1系統開發目的
（1）大大提高超市的運作效率；
（2）通過全面的信息採集和處理，輔助提高超市的決策水平；
（3）使用本系統，可以迅速提升超市的管理水平，為降低經營成本， 提高效益，增強超市擴張力， 提供有效的技術保障。
1.2背景說明
21世紀，超市的競爭也進入到了一個全新的領域，競爭已不再是規模的競爭，而是技術的競爭、管理的競爭、人才的競爭。技術的提升和管理的升級是超市業的競爭核心。零售領域目前呈多元發展趨勢，多種業態：超市、倉儲店、便利店、特許加盟店、專賣店、貨倉等相互並存。如何在激烈的競爭中擴大銷售額、降低經營成本、擴大經營規模，成為超市營業者努力追求的目標。
1.3項目確立
針對超市的特點，為了幫助超市解決現在面臨的問題，提高小型超市的競爭力，我們將開發以下系統：前台POS銷售系統、後台管理系統，其中這兩個子系統又包含其它一些子功能。
1.4應用范圍
本系統適應於各種小型的超市。
1.5 定義
（1）商品條形碼：每種商品具有唯一的條形碼，對於某些價格一樣的商品，可以使用自定義條形碼。
（2）交易清單：包括交易的流水賬號、每類商品的商品名、數量、該類商品的總金額、交易的時間、負責本次收銀的員工號。
（3）商品積壓：在一定時期內，遠無法完成銷售計劃的商品會造成積壓。
（4）促銷：在一定時期內，某些商品會按低於原價的促銷價格銷售。
庫存告警提示：當商品的庫存數量低於庫存報警數量時發出提示。
（5）盤點：計算出庫存、銷售額、盈利等經營指標。
1.6 參考資料
《資料庫原理及設計》 陶宏才編 清華大學出版社
《SQL Server 2000 實用教程》范立南編 清華大學出版社
《SQL Server 2000 編程員指南》李香敏編 北京希望電子出版社
《輕松搞定 SQL Server 2000 程序設計》Rebecca M.Riordan編
《軟體工程規范》Watts S.Humphrey編 清華大學出版社
《軟體工程理論與實踐》 Shari Lawrence Pfleeger編 清華大學出版社
《軟體需求分析》 Swapna Kishore編 機械工業出版社
《軟體工程思想》 林銳編
2、邏輯分析與詳細分析
2.1系統功能
（1）、零售前台（POS）管理系統，本系統必須具有以下功能：
商品錄入：根據超巿業務特點制定相關功能，可以通過輸入唯一編號、掃描條形碼、商品名稱等來實現精確或模糊的商品掃描錄入。該掃描錄入方法可以充分保證各種電腦操作水平層次的人員均能准確快速地進行商品掃描錄入。
收銀業務：通過掃描條形碼或者直接輸入商品名稱（對於同類多件商品採用一次錄入加數量的方式）自動計算本次交易的總金額。在顧客付款後，自動計算找零，同時列印交易清單（包括交易的流水賬號、每類商品的商品名、數量、該類商品的總金額、交易的時間、負責本次收銀的員工號）。如果顧客是本店會員並持有本人會員卡，則在交易前先掃描會員卡，並對所購物品全部實行95折優惠，並將所購物品的總金額累計到該會員的總消費金額中。 會員卡的有效期限為一年，滿一年未續卡者，該會員卡將被注銷。
安全性：OS登陸、退出、換班與操作鎖定等許可權驗證保護；斷電自動保護最大限度防止意外及惡意非法操作。
獨立作業：有的斷網收銀即在網路伺服器斷開或網路不通的情況下，收銀機仍能正常作業
(2)、後台管理系統，本系統必須具備以下功能
進貨管理： 根據銷售情況及庫存情況，自動制定進貨計劃（亦可手工制定修改），可以避免盲目進貨造成商品積壓。 按計劃單有選擇性地進行自動入庫登記。 綜合查詢列印計劃進貨與入庫記錄及金額。
銷售管理： 商品正常銷售、促銷與限量、限期及禁止銷售控制。 綜合查詢各種銷售明細記錄、各地收銀員收銀記錄以及交結賬情況等。 按多種方式統計生成銷售排行榜，靈活察看和列印商品銷售日、月、年報表。
庫存管理： 綜合查詢庫存明細記錄。 庫存狀態自動告警提示。如庫存過剩、少貨、缺貨等。軟體為您預警，避免庫存商品積壓損失和缺貨。 庫存自動盤點計算。
人員管理： 員工、會員、供貨商、廠商等基本信息登記管理。 員工操作許可權管理。 客戶銷售許可權管理。
（3）系統結構
系統總體結構
模塊子系統結構
功能描述：商品錄入子系統要求能快速錄入商品，因此必須支持條形碼掃描。
功能描述：收銀業務子系統能計算交易總額，列印交易清單，並根據會員卡打折。
功能描述：進貨管理子系統可以根據庫存自動指定進貨計劃，進貨時自動等級，以及提供查詢和列印計劃進貨與入庫記錄的功能。
功能描述：銷售管理子系統可以控制某商品是否允許銷售，查詢每種商品的銷售情況並產生年、月、日報表，同時可以生成銷售排行榜。
功能描述：庫存管理子系統提供查詢庫存明細記錄的基本功能，並根據庫存的狀態報警，以及自動盤點計算。
功能描述：人員管理子系統提供基本信息登記管理，員工操作許可權管理，客戶銷售許可權管理的功能。
2.2、流程圖
前台管理系統
頂層DFD圖
第0層DFD圖
第1層DFD圖
2.3、戶類型與職能
（1）、員工（營業員）：
通過商品條形碼掃描輸入商品到購買清單
操作軟體計算交易總金額
操作軟體輸出交易清單
對會員進行會員卡掃描以便打折
（2）、：超市經理
操作軟體錄入商品，供貨商，廠商
操作軟體制定進貨計劃
查詢列印計劃進貨與入庫記錄
操作軟體控制商品銷售與否
查詢列印銷售情況
操作軟體生成銷售排行榜
查詢庫存明細記錄
根據軟體發出的庫存告警進行入貨
操作軟體進行盤點計算
（3）、總經理：
基本信息登記管理
員工操作許可權管理
客戶銷售許可權管理
2.4、統開發步驟
確定參與者和相關的用況
為每個用況設計過程
建立順序圖，確定每個腳本中對象的協作
創建類，確定腳本中的對象
設計, 編碼, 測試, 集成類
為過程編寫系統測試案例
運行測試案例，檢驗系統
2.5、系統環境需求
系統模式
本系統採用C/S模式作為開發模式
硬體環境
伺服器端：
高性能的計算機一台，
普通的雙絞線作為連接。
客戶端： 普通的計算機或者工作站，
普通的雙絞線作為連接。
軟體環境
伺服器端：安裝SQL Server 2000的伺服器版本，
安裝windows 2000伺服器版本，
配置了諾頓等必須的防毒軟體。
客戶端： 安裝SQL Server2000的伺服器版本，
安裝了VB等可視化開發工具軟體，
安裝windows2000伺服器版本。
2.6、系統安全問題
信息系統盡管功能強大，技術先進，但由於受到自身體系結構，設計思路以及運行機制等限制，也隱含許多不安全因素。常見因素有：數據的輸入，輸出，存取與備份，源程序以及應用軟體，資料庫，操作系統等漏洞或缺陷，硬體，通信部分的漏洞，企業內部人員的因素，病毒，「黑客」等因素。因此，為使本系統能夠真正安全，可靠，穩定地工作，必須考慮如下問題：為保證安全，不致使系統遭到意外事故的損害，系統因該能防止火，盜或其他形式的人為破壞。
系統要能重建
系統應該是可審查的
系統應能進行有效控制，抗干擾能力強
系統使用者的使用許可權是可識別的
3、基於UML的建模
3.1語義規則
用例模型（use cases view）（用例視圖）的基本組成部件是用例（use case）、角色(actor)和系統(system)。用例用於描述系統的功能，也就是從外部用戶的角度觀察，系統應支持哪些功能，幫助分析人員理解系統的行為，它是對系統功能的宏觀描述，一個完整的系統中通常包含若干個用例，每個用例具體說明應完成的功能，代表系統的所有基本功能（集）。角色是與系統進行交互的外部實體，它可以是系統用戶，也可以是其它系統或硬體設備，總之，凡是需要與系統交互的任何東西都可以稱作角色。系統的邊界線以內的區域（即用例的活動區域）則抽象表示系統能夠實現的所有基本功能。在一個基本功能（集）已經實現的系統中，系統運轉的大致過程是：外部角色先初始化用例，然後用例執行其所代表的功能，執行完後用例便給角色返回一些值，這個值可以是角色需要的來自系統中的任何東西。
UML：是一種標準的圖形化建模語言，它是面向對象分析與設計的一種標准表示；它不是一種可視化的程序設計語言而是一種可視化的建模語言；不是工具或知識庫的規格說明而是一種建模語言規格說明是一種表示的標准；不是過程也不是方法但允許任何一種過程和方法使用它。
用例（use case）：
參與者（actor）：
3.2、UML模型
3.21、系統UML模型
3.22、子系統UML模型
（1）零售前台（POS）管理系統用例視圖
（2）後台管理系統用例視圖
3.3、系統實現圖
4、超市銷售系統概念設計文檔
（1）、系統ER圖
（2）、系統ER圖說明
1) 商店中的所有用戶（員工）可以銷售多種商品，每種商品可由不同用戶（員工）銷售；
2) 每個顧客可以購買多種商品，不同商品可由不同顧客購買；
3) 每個供貨商可以供應多種不同商品，每種商品可由多個供應商供應。
（3）、視圖設計
1) 交易視圖(v_Dealing)——用於查詢交易情況的視圖；
2) 計劃進貨視圖(v_PlanStock)——用於查詢進貨計劃的視圖；
3) 銷售視圖(v_Sale)——用於查詢銷售明細記錄的視圖；
4) 入庫視圖(v_Stock)——用於查詢入庫情況的視圖。
5、邏輯設計文檔
（1）、系統關系模型
a) 商品信息表（商品編號，商品名稱，價格，條形碼，促銷價格，促銷起日期，促銷止日期，允許打折，庫存數量，庫存報警數量，計劃進貨數，允許銷售，廠商編號，供貨商編號）
b) 用戶表（用戶編號，用戶名稱，用戶密碼，用戶類型）
c) 會員表（會員編號，會員卡號，累積消費金額，注冊日期）
d) 銷售表（銷售編號，商品編號，銷售數量，銷售金額，銷售日期）
e) 交易表（交易編號，用戶名稱，交易金額，會員卡號，交易日期）
f) 進貨入庫表（入庫編號，入庫商品編號，入庫數量，單額，總額，入庫日期，計劃進貨日期，入庫狀態）
g) 供貨商表（供貨商編號，供貨商名稱，供貨商地址，供貨商電話）
h) 廠商表（廠商編號，廠商名稱，廠商地址，廠商電話）
（2）、系統資料庫表結構
資料庫表索引
表名 中文名
MerchInfo 商品信息表
User 用戶表
Menber 會員表
Sale 銷售表
Dealing 交易表
Stock 進貨入庫表
Provide 供貨商表
Factory 廠商表
商品信息表(MerchInfo)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
MerchID int 4 P Not null 商品編號
MerchName Varchar 50 Not null 商品名稱
MerchPrice Money 4 Not null 價格
MerchNum Int 4 Not null 庫存數量
CautionNum Int 4 Not null 庫存報警數量
PlanNum Int 4 null 計劃進貨數
BarCode Varchar 50 Not null 條形碼
SalesProPrice Money 4 促銷價格
SalesProDateS Datetime 8 促銷起日期
SalesProDateE Datetime 8 促銷止日期
AllowAbate Int 4 Not null 允許打折
AllowSale Int 4 Not null 允許銷售
FactoryID Varchar 10 F Not null 廠商編號
ProvideID Varchar 10 F Not null 供貨商編號
用戶表(User)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
UserID varchar 10 P Not null 用戶編號
UserName Varchar 25 Not null 用戶名稱
UserPW Varchar 50 Not null 用戶密碼
UserStyle Int 4 Not null 用戶類型
會員表(Menber)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
MemberID Varchar 10 P Not null 會員編號
MemberCard Varchar 20 Not null 會員卡號
TotalCost Money 4 Not null 累積消費金額
RegDate Datetime 8 Not null 注冊日期
銷售表(Sale)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
SaleID Varchar 10 P Not null 銷售編號
MerChID Varchar 10 F Not null 商品編號
SaleDate Datetime 8 Not null 銷售日期
SaleNum Int 4 Not null 銷售數量
SalePrice Money 4 Not null 銷售單額
交易表(Dealing)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
DealingID Varchar 10 P Not null 交易編號
DealingPrice Money 4 Not null 交易金額
DealingDate Money 4 Not null 交易日期
MemberID Varchar 10 會員卡號
UserName Varchar 10 F Not null 用戶名稱
入庫紀錄表(Stock)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
StockID Varchar 10 P Not null 入庫編號
MerchID Varchar 10 F Not null 入庫商品編號
MerchNum Int 4 Not null 入庫數量
MerchPrice Money 4 Not null 單額
TotalPrice Money 4 Not null 總額
StockDate Datetime 8 Datetime 入庫日期
PlanDate Datetime 8 Datetime 計劃進貨日期
StockState Int 4 Not null 入庫狀態
供貨商表(Provide)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
ProvideID varchar 10 P Not null 供貨商編號
ProvideName Varchar 50 Not null 供貨商名稱
ProvideAddress Varchar 250 供貨商地址
ProvidePhone Varchar 25 供貨商電話
廠商表(Provide)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
FactoryID varchar 10 P Not null 廠商編號
FactoryName Varchar 50 Not null 廠商名稱
FactoryAddress Varchar 250 廠商地址
FactoryPhone Varchar 25 廠商電話
6、物理設計文檔
/*----------創建資料庫----------*/
create database SuperMarketdb
on primary
(
name=SuperMarketdb,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.mdf',
size=100MB,
maxsize=200MB,
filegrowth=20MB
)
log on
(
name=SuperMarketlog,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.ldf',
size=60MB,
maxsize=200MB,
filegrowth=20MB
)
go
/*----------創建基本表----------*/
use [SuperMarketdb]
go
/*創建交易表*/
CREATE TABLE Dealing (
DealingID int identity(1,1) Primary key ,
DealingDate datetime NOT NULL ,
DealingPrice money NOT NULL ,
UserName varchar(25) NULL ,
MemberCard varchar(20) NULL
)
GO
/*創建廠商表*/
CREATE TABLE Factory (
FactoryID varchar(10) Primary key ,
FactoryName varchar(50) NOT NULL ,
FactoryAddress varchar(250) NULL ,
FactoryPhone varchar(50) NULL
)
GO
/*創建會員表*/
CREATE TABLE Member (
MemberID varchar(10) Primary key ,
MemberCard varchar(20) NOT NULL ,
TotalCost money NOT NULL ,
RegDate datetime NOT NULL
)
GO
/*創建商品信息表*/
CREATE TABLE MerchInfo (
MerchID int identity(1,1) Primary key ,
MerchName varchar(50) Unique NOT NULL ,
MerchPrice money NOT NULL ,
MerchNum int NOT NULL ,
CautionNum int NOT NULL ,
PlanNum int NOT NULL ,
BarCode varchar(20) Unique NOT NULL ,
SalesProPrice money NULL ,
SalesProDateS datetime NULL ,
SalesProDateE datetime NULL ,
AllowAbate int NOT NULL ,
AllowSale int NOT NULL ,
FactoryID int NOT NULL ,
ProvideID int NOT NULL
)
GO
/*創建供應商表*/
CREATE TABLE Provide (
ProvideID varchar(10) Primary key ,
ProvideName varchar(50) NOT NULL ,
ProvideAddress varchar(250) NULL ,
ProvidePhone varchar(25) NULL
)
GO
/*創建銷售表*/
CREATE TABLE Sale (
SaleID int identity(1,1) Primary key ,
MerChID int NOT NULL ,
SaleDate datetime NOT NULL ,
SaleNum int NOT NULL,
SalePrice money NOT NULL
)
GO
/*創建入庫表*/
CREATE TABLE Stock (
StockID int identity(1,1) Primary key ,
MerchID int NOT NULL ,
MerchNum int NOT NULL ,
MerchPrice money NULL ,
TotalPrice money NULL ,
PlanDate datetime NULL ,
StockDate datetime NULL,
StockState int NOT NULL
)
GO
/*創建用戶表*/
CREATE TABLE User (
UserID varchar(10) Primary key ,
UserName varchar(25) NOT NULL ,
UserPW varchar(50) NOT NULL ,
UserStyle int NOT NULL ,
)
GO
/*----------創建表間約束----------*/
/*商品信息表中廠商編號、供應商編號分別與廠商表、供應商表之間的外鍵約束*/
ALTER TABLE MerchInfo ADD
CONSTRAINT [FK_MerchInfo_Factory] FOREIGN KEY
(
[FactoryID]
) REFERENCES Factory (
[FactoryID]
),
CONSTRAINT [FK_MerchInfo_Provide] FOREIGN KEY
(
[ProvideID]
) REFERENCES Provide (
[ProvideID]
)
GO
/*銷售表中商品編號與商品信息表之間的外鍵約束*/
ALTER TABLE Sale ADD
CONSTRAINT [FK_Sale_MerchInfo] FOREIGN KEY
(
[MerChID]
) REFERENCES MerchInfo (
[MerchID]
) ON DELETE CASCADE
GO
/*入庫表中商品編號與商品信息表之間的外鍵約束*/
ALTER TABLE Stock ADD
CONSTRAINT [FK_Stock_MerchInfo] FOREIGN KEY
(
[MerchID]
) REFERENCES MerchInfo (
[MerchID]
) ON DELETE CASCADE
GO
/*----------創建索引----------*/
/*在交易表上建立一個以交易編號、交易日期為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Dealing ON Dealing(DealingID, DealingDate)
GO
/*在商品信息表上建立一個以商品編號為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_MerchInfo ON MerchInfo(MerchID)
GO
/*在銷售表上建立一個以銷售編號、銷售日期為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Sale ON Sale(SaleID, SaleDate)
GO
/*在入庫表上建立一個以入庫編號、入庫日期、商品編號為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Stock ON Stock(StockID, StockDate, MerchID)
GO
/*----------創建視圖----------*/
/*創建用於查詢交易情況的視圖*/
CREATE VIEW v_Dealing
AS
SELECT DealingDate as 交易日期,
UserName as 員工名稱,
MemberCard as 會員卡號,
DealingPrice as 交易金額
FROM Dealing
GO
/*創建用於查詢進貨計劃的視圖*/
CREATE VIEW v_PlanStock
AS
SELECT Stock.StockID as SID,
MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
Factory.FactoryName as 廠商,
Provide.ProvideName as 供貨商,
Stock.MerchNum as 計劃進貨數量,
Stock.PlanDate as 計劃進貨日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=0
GO
/*創建用於查詢銷售明細記錄的視圖*/
CREATE VIEW v_Sale
AS
SELECT MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
MerchInfo.MerchPrice as 商品價格,
Sale.SalePrice as 銷售價格,
Sale.SaleNum as 銷售數量,
Sale.SaleDate as 銷售日期
FROM Sale INNER JOIN
MerchInfo ON Sale.MerChID = MerchInfo.MerchID
GO
/*創建用於查詢入庫情況的視圖*/
CREATE VIEW v_Stock
AS
SELECT MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
Factory.FactoryName as 廠商,
Provide.ProvideName as 供貨商,
Stock.MerchPrice as 入庫價格,
Stock.MerchNum as 入庫數量,
Stock.TotalPrice as 入庫總額,
Stock.StockDate as 入庫日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=1
GO
7、小結
和傳統管理模式相比較，使用本系統，毫無疑問會大大提高超市的運作效率，輔助提高超市的決策水平，管理水平，為降低經營成本， 提高效益，減少差錯，節省人力，減少顧客購物時間，增加客流量，提高顧客滿意度，增強超市擴張能力， 提供有效的技術保障。
由於開發者能力有限，加上時間倉促，本系統難免會出現一些不足之處，例如：
本系統只適合小型超市使用，不能適合中大型超市使用；
超市管理系統涉及范圍寬，要解決的問題多，功能復雜，實現困難，但由於限於時間，本系統只能做出其中的一部分功能；
對於以上出現的問題，我們深表歉意，如發現還有其它問題，希望老師批評指正。
J. 便利店應怎樣升級硬體設施
從表面上看，傳統便利店的升級和創新是技術和數據直接促進了便利店人員，商品和領域之間的關系，但實質上，消費升級促進了便利店的轉型升級。
在互聯網條件和消費者要求多元化的新時代背景下，經營便利店務必遵照五個核心原則：
便利店一：提高消費者感受
在消費理念升級下，消費者不再關注商品的價格，反而是高度重視購物體驗，消費者更願意為消費者的感受付出應有的代價。比如，人性化飯店，網紅奶茶店和快閃店的盛行證明了這一點。
便利店二：擺脫時間與空間限定
由於手機和移動網路的廣泛應用，交易不會再只產生在網上商城和線下商城。它與消費者的各種各樣生活情景有直接的關系。消費者到哪去，他們就在哪兒產生交易，情景打破了區域的限定。因此，僅有線上和離線實際操作才可以擺脫時間與空間的局限。
便利店三：多樣化
小區便利店：務必達到社區的多元化要求。它不但滿足住戶每日必須的主要產品，還應增加其他產品，早餐午餐，特色食品和別的類型，以提升店鋪的總體利潤。還有存放快遞，付款水電氣，鮮花配送，家政保潔和別的社區便民服務等，有多元化的便利店才更具有競爭力。
便利店四：消費者智能化
現階段，獲得流量的成本費增加，便利店可以從2個層面來創建一個大型的資料庫：首先，利用內部結構和外部數據網路資源來實現對消費者人像和生活情景的掌握。其次，便利店可以使用微信等方式創建vip會員，這不僅僅將其作為品牌營銷，營銷通告，創建知名品牌黏合方式，在一定程度上，會員的溝通交流能夠更清楚地掌握關鍵消費人群的生活消費習慣及其產品與服務感受的關鍵信息。
