促銷資料庫設計

Ⅰ 紅包活動怎麼設計資料庫表

僅供參考
創建資料庫里最基本的應該就是建表，建索引、存儲過程等一系列操作了。談到表就不得不談到實體。
一、數據實體
什麼是實體，客觀存在並且可以相互區別的事物稱為實體。這里我們就簡單的把它理解為一個表吧，描述實體的特性，我們就把他們稱為了屬性。也可以說當我們把一個資料庫表當作一個實體，那麼它裡面的所有欄位是不是就是一個屬性了呢？結果是肯定的。
二、實體間的聯系
我想說的是，很簡單，資料庫里表跟表間的關系莫過於三種：一對一；多對多；一對多。
一對一其實就是說我們建的主表跟相關聯的表之間是一一對應的，比如說，我建了一個學生基本信息表：t_student,然後我又建了一個成績表，裡面有個外鍵，studentID，學生基本信息表裡的欄位studentID和成績表裡的studentID就是一對一。
一對多，也是類似，我另外建一個班級表，而每個班級有多個學生，每個學生就對應一個班級，對班級來說當然就是一對多了。
多對多，我還舉這個例子，我建個選課表，可能有許多科目，每個科目有很多學生選，而每個學生又可以選擇多個科目。這就是多對多了。
三、基本表的完整性
(1) 原子性。基本表中的欄位是不可再分解的。
(2) 原始性。基本表中的記錄是原始數據（基礎數據）的記錄。
(3) 演繹性。由基本表與代碼表中的數據，可以派生出所有的輸出數據。
(4) 穩定性。基本表的結構是相對穩定的，表中的記錄是要長期保存的。
這是基本表的完整性，也是它特有的。這里我想說的是，在資料庫里還有幾種表也是常用的那就是中間表和臨時表。
1、中間表
中間表是針對多對多關系的，就比如做公交查詢系統。裡面有兩個表，分別是車站表、線路表。這里我們起個名字叫：t_busstation 、t_road，根據常識我們也知道，一個站有多個線路經過，而每個線路又有多個車站，怎麼才能將兩個表聯系起來呢，如果是一對一，一對多，我們一個表，兩個表就可以將他們實現了，但是多對多呢，這樣我們就必須藉助中間表用來連接兩個表。一般中間表都是有一個本表的自增主鍵，還有另外兩個表的主鍵。中間表是沒有屬性的因為它不是一個基本表。
2、臨時表
在本次項目中，我們就要用到臨時表，首先來看看什麼是臨時表吧。這是我從網上書上查到的。因為我們用的是MS SQL Server 2000資料庫，而在這個資料庫里是支持臨時表的。
臨時表：其實就是那些以#號開頭為名字的數據表，它主要是用來存放臨時數據的，當用戶斷開連接但沒有出去臨時表裡的數據時，系統會自動把臨時表裡的數據清空。這里要說一點，臨時表是放在系統資料庫 tempdb中的，而不是當前資料庫。
臨時表總共是分兩種：本地臨時表和全局臨時表。
（1）這里我們需要了解的就是，在資料庫中本地臨時表是以一個#開頭的，這種臨時表只對當前的資料庫用戶可見，而其他的用戶是不可見的。當資料庫實例斷開後當然也就丟失了數據了，不管是顯式清空還是系統回收。
（2）還有一個就是全局臨時表。它是以「##」開頭的，而且是對於所有的用戶都是可見的，當你斷開資料庫實例連接時，只要還有別的系統項目在引用它，連著資料庫，那麼數據就存在，只有當別的系統也斷開連接時，系統才會清除全局臨時表的數據。
下面是建立臨時表的語句:
本地臨時表：
create table #student
(
studentID int ,
studentName nvarchar (40),
classID int
)

全局臨時表：
create table ##student
(
studentID int ,
studentName nvarchar (40).
classID int
)
這里我們也可以用SQL語句完成：
select * from employee into #student

現在就來看看三大範式。
第一範式：如果每列(或者每個屬性)都是不可再分的最小數據單元(也稱為最小的原子單元),則滿足第一範式.比如一個工人的基本信息表，裡面有工人的工號，性別，年齡，這些屬性都是不可分割的，所以這個表就符合了第一範式。
第二範式： 就是在第一範式的基礎上延伸，使之表裡的每個欄位都與主鍵發生關系。假如一個關系滿足第一範式,並且除了主鍵以外的其它欄位,都依賴於該主鍵,則滿足第二範式.
例如:訂單表(訂單編號、產品編號、定購日期、價格、……)，"訂單編號"為主鍵，"產品編號"和主鍵列沒有直接的關系，即"產品編號"列不依賴於主鍵列，這個列我們就可以把它刪除。
第三範式：在第二範式的基礎上更進一步，也就是為了實現表裡的列都與主鍵列直接相關，不是間接相關。這個我們可以用「Armstrong 公理」中的傳遞規則來推理。
我們來看一下它的定義：
設U是關系模式R 的屬性集，F 是R 上成立的只涉及U 中屬性的函數依賴集。若X→Y 和 Y→Z在R 上成立，則X →Z 在R 上成立。因此我們就來看在網上搜索到的例子：例如:訂單表(訂單編號，定購日期，顧客編號，顧客姓名，……)，初看該表沒有問題，滿足第二範式，每列都和主鍵列"訂單編號"相關，再細看你會發現"顧客姓名"和"顧客編號"相關，"顧客編號"和"訂單編號"又相關，最後經過傳遞依賴，"顧客姓名"也和"訂單編號"相關。為了滿足第三範式，應去掉"顧客姓名"列，放入客戶表中。
這里其實就是為了說明資料庫的表裡步要出現冗餘，在顧客表裡已經有了"顧客姓名"了，而在訂單表裡就別出現了，而直接根據顧客編號相關聯就可以，否則造成資源浪費。
以上就是三大範式。
延伸：我們來看這三大範式：
第一範式：1NF是對屬性的原子性約束，要求屬性具有原子性，不可再分解；
第二範式：2NF是對記錄的惟一性約束，要求記錄有惟一標識，即實體的惟一性；
第三範式：3NF是對欄位冗餘性的約束，即任何欄位不能由其他欄位派生出來，它要求欄位沒
有冗餘。
其實在設計資料庫的時候我們最多的要遵循的就是第三範式，但是並不是越滿足第三範式資料庫就設計的越完美，這種錯誤是錯誤的。有時候增加點冗餘相反的會提高訪問速率，因此在實際的設計過程中應降低對範式的要求。
以前對數據冗餘並不是很了解，在網路知道里的定義是這樣的：在一個數據集合中重復的數據稱為數據冗餘. 但是不是說我們表的主鍵在其他表裡重復出現就是冗餘，這不是，而是為了連接兩個表。只有非鍵欄位就是既不是主鍵外鍵等約束的鍵如果重復出現，就會形成數據冗餘。數據冗餘也包括重復性冗餘和派生冗餘。比如工人表裡有"基本工資"，"獎金"兩列，然後還有一個"總工資"的列，這個總工資就是派生冗餘。低級的重復性冗餘一定要避免，杜絕，但是像派生冗餘還是提倡的因為它能提高訪問的效率。

Ⅱ 請問商品活動管理資料庫該怎麼去設計，就是商品有時打折促銷贈送禮品會用到的，我有一個積分規則表，商品

商品表
某化妝品
某電器
某服裝

積分類別表
化妝品積分
普通積分

積分規則表
商品 --> 積分類別 開始時間 結束時間 x系數
化妝品 化妝品積分 2011-1-1 2011-1-29 2 [比如這個是雙倍積分]
化妝品 化妝品積分 2011-1-30 2011-2-10 0 [比如促銷期間不積分]
化妝品 化妝品積分 2011-2-11 2099-12-31 2 [促銷結束後恢復積分]
服裝 普通積分 2011-1-1 2099-12-31 1

會員卡類別
無卡客戶
普通會員卡
金卡

折扣
商品 會員卡類別 開始時間 結束時間 折扣
某化妝品 無卡客戶 2011-1-30 2011-2-10 0.9 [此期間9折]
某化妝品 普通會員卡 2011-1-30 2011-2-10 0.8 [此期間8折]
某化妝品 金卡 2011-1-30 2011-2-10 0.7 [此期間7折]

就給個例子,僅供參考.

Ⅲ 什麼是資料庫營銷以及它的優勢是什麼

什麼是資料庫營銷
所謂資料庫營銷就是企業通過收集和積累消費者的大量信息，經過處理後預測消費者有多大可能去購買某種產品，以及利用這些信息給產品以精確定位，有針對性地製作營銷信息，以達到說服消費者去購買產品的目的。
資料庫營銷的優勢
資料庫營銷在歐美已經得到了廣泛的應用。在中國大陸地區，也已經開始呈現「星星之火，快速燎原」之勢頭。包括DM(Direct Mail, 定向直郵), EDM(Email DM，電子郵件營銷) ,E-Fax(網路傳真營銷)和SMS(Short Message Server,短消息服務)等在內的多種形式的資料庫營銷手段，得到了越來越多的中國企業的青睞。
之所以越來越多的企業開始選擇資料庫營銷，這與它相對傳統營銷所具有的獨特優勢是密不可分的。
一、可測試性
資料庫營銷就像科學實驗，每推進一步，都可以精心的測試，其結果還可以進行分析。假設你有一間酒吧，可以發出一封郵件，宣布所有光臨的女士都可以免費獲得一杯雞尾酒。而在另一封郵件中，你可以宣布除周六、周日外所有顧客都可以獲得8折優惠。在進行一段時間的小規模測試後，計算哪一封郵件產生的回報最高，之後就運用獲得最佳反應的方案進行更大規模的郵寄。不管企業的大小如何，只要運用適當的形式，都可以進行小規模的測試，以便了解哪種策略最有可能取得成功。
二、可測度
資料庫營銷是惟一一種可測度的廣告形式。你能夠准確地知道如何獲得客戶的反應以及這些反映來自何處。這些信息將被用於繼續、擴展或重新制定、調整你的營銷計劃。
而傳統的廣告形式（報紙、雜志、網路、電視等）只能面對一個模糊的大致的群體，究竟目標人群佔多少無法統計，所以效果和反饋率總是讓人失望。正如零售商巨頭Wanamaker說過：「我知道花在廣告上的錢，有一半被浪費掉了，但我不知道是哪一半」。
三、獲得更多的長期忠實客戶
權威專家分析，維持一個老顧客所需的成本是尋求一個新顧客成本的0.5倍，而要使一個失去的老顧客重新成為新顧客所花費的成本則是尋求一個新客戶成本的10倍。如果比競爭對手更了解顧客的需求和慾望，留住的最佳顧客就更多，就能創造出更大的競爭優勢。用資料庫營銷經常地與消費者保持溝通和聯系，可以維持和增強企業與消費者之間的感情紐帶。另外，運用儲存的消費記錄來推測其未來消費者行為具有相當精確性，從而使企業能更好地滿足消費者的需求，建立起長期的穩定的客戶關系。
四、降低成本，提高營銷效率
資料庫營銷可以使企業能夠集中精力於更少的人身上，最終目標集中在最小消費單位到個人身上，實現准確定位。目前美國已有56％的企業正在建立資料庫，85％的企業認為他們需要資料庫營銷來加強競爭力。由於運用消費者資料庫能夠准確找出某種產品的目標消費者，企業就可以避免使用昂貴的大眾傳播媒體，可以運用更經濟的促銷方式，從而降低成本，增強企業的競爭力。具有關資料統計，運用資料庫技術進行篩選消費者，其郵寄宣傳品的反饋率，是沒有運用資料庫技術進行篩選而發送郵寄宣傳品的反饋率的10倍以上。
五、企業制勝的秘密武器
傳統營銷中，運用大眾傳媒（電視、報紙、雜志、網路等）大規模地宣傳新品上市，或實施新的促銷方案，容易引起競爭對手的注意，使他們緊跟其後推出對抗方案，勢必影響預期的效果。而運用資料庫營銷，可與消費者建立緊密關系，一般不會引起競爭對手的注意，避免公開對抗。如今，很多知名企業都將這種現代化的營銷手段運用到了自身的企業，將其作為一種秘密武器運用於激烈的市場競爭中去，從而在市場上站穩了腳跟。
由此可見資料庫營銷以一種新型市場營銷方式結合它的便利性推動了企業與消費者之間的互動。

Ⅳ 網站消費優惠活動表資料庫怎麼設計

「消費滿多少」 做一個欄位
「減多少」 做一個欄位

訂單結算時：程序中檢查訂單商品的ID是否在商品優惠表中，是的話，根據ID把這些價格加起來和「消費滿多少」做比較，超過了就用這個數來減去「減多少」這個欄位。
還不明白，留下QQ，再詳說

Ⅳ 什麼是資料庫營銷資料庫營銷的概念是什麼

資料庫營銷是為了實現接洽、交易和建立客戶關系等目標而建立、維護和利用顧客數據與其他顧客資料的過程。資料庫營銷（Database Marketing Service，DMS）是在IT、Internet與 Database技術發展上逐漸興起和成熟起來的一種市場營銷推廣手段，在企業市場營銷行為中具備廣闊的發展前景。它不僅僅是一種營銷方法、工具、技術和平台，更重要的是一種企業經營理念，也改變了企業的市場營銷模式與服務模式，從本質上講是改變了企業營銷的基本價值觀。通過收集和積累消費者大量的信息，經過處理後預測消費者有多大可能去購買某種產品，以及利用這些信息給產品以精確定位，有針對性地製作營銷信息達到說服消費者去購買產品地目的。通過資料庫的建立和分析，各個部門都對顧客的資料有詳細全面的了解，可以給予顧客更加個性化的服務支持和營銷設計，使 「 一對一的顧客關系管理 」 成為可能。

資料庫營銷在西方發達國家的企業里已相當普及，在美國，1994年Donnelley Marketing 公司的調查顯示，56% 的零售商和製造商有營銷資料庫，10%的零售商和製造商正在計劃建設營銷資料庫，85%的零售商和製造商認為在本世紀末，他們將需要一個強大的營銷資料庫來支持他們的競爭實力。從全球來看，資料庫營銷作為市場營銷的一種形式，正越來越受到企業管理者的青睞，在維系顧客、提高銷售額中扮演著越來越重要的作用。

一、宏觀功能——市場預測和實時反應

客戶資料庫的各種原始數據，可以利用 「 數據挖掘技術 」 和 「 智能分析 」 在潛在的數據中發現贏利機會。基於顧客年齡、性別、人口統計數據和其它類似因素，對顧客購買某一具體貨物可能性作出預測；能夠根據資料庫中顧客信息特徵有針對性的判定營銷策略，促銷手段，提高營銷效率，幫助公司決定製造適銷的產品以及使產品制定合適的價格；可以以所有可能的方式研究數據，按地區、國家、顧客大小、產品、銷售人員、甚至按郵編，從而比較出不同市場銷售業績，找出數字背後的原因，挖掘出市場潛力。企業產品質量上或者功能的反饋信息首先通過市場、銷售、服務等一線人員從面對面的顧客口中得知，把有關的信息整理好以後，輸入資料庫，定期對市場上的顧客信息進行分析，提出報告，幫助產品在工藝或功能上的改善和完美，產品開發部門作出前瞻性的研究和開發；管理人員可以根據市場上的實時信息隨時調整生產和原料的采購，或者調整生產產品的品種，最大限度的減少庫存，做到 「 適時性生產 」 （ JIT ）。

二、微觀功能——分析每位顧客的贏利率

事實上，對於一個企業來說，真正給企業帶來豐厚利潤的顧客只佔所有顧客中的 20% ，他們是企業的最佳顧客，贏利率是最高的，對這些顧客，企業應該提供特別的服務、折扣或獎勵，並要保持足夠的警惕，因為競爭對手也是瞄準這些顧客發動競爭攻擊的。然而絕大多數的企業的顧客戰略只是獲取顧客，很少花精力去辨別和保護他們的最佳顧客，同時去除不良顧客；他們也很少花精力考慮到競爭者手中去策反顧客，增加產品和服務，來提高贏利率。利用企業資料庫中的詳細資料我們能夠深入到信息的微觀程度，加強顧客區分的統計技術，計算每位顧客的贏利率，然後去搶奪競爭者的最佳顧客，保護好自己的最佳顧客，培養自己極具潛力的顧客，驅逐自己最差的顧客。通用電氣公司的消費者資料庫能顯示每個顧客的各種詳細資料，保存了每次的交易記錄。他們可以根據消費者購買公司家用電器的歷史，來判斷誰對公司和新式錄象機感興趣，能確認誰是公司的大買主，並給他們送上價值30 美圓的小禮物，以換取他們對公司產生下一次的購買。

目前在我國，傳統的營銷方式仍占據著相當的地位，資料庫營銷只是對傳統營銷方式的補充和改變。但從長期看，資料庫營銷必將隨著企業管理水平、尤其是營銷管理水平的提升而得到創新使用。現在一些具有領先觀念的企業如上海羅氏、通用汽車、廣東美的已經建設了CRM 系統。

隨著經濟的日益發展和信息技術對傳統產業的改造，消費者的個性化需求的滿足成為了可能，中國加入WTO 以後，企業將面臨更加嚴峻的形勢，如何在這場強敵環飼的角力中勝出，需要全方位的提升企業的競爭力——特別是企業的客戶信息能力，作為企業經營戰略中非常重要的營銷體制也必須吸收西方先進的營銷理念和手段，革除傳統營銷模式的弊端，資料庫營銷是先進的營銷理念和現代信息技術的結晶，必然是企業未來的選擇。

資料庫營銷的基本作用

（1）更加充分地了解顧客的需要。

（2）為顧客提供更好的服務。顧客資料庫中的資料是個性化營銷和顧客關系管理的重要基礎。

（3）對顧客的價值進行評估。通過區分高價值顧客和一般顧客，對各類顧客採取相應的營銷策略。

（4）了解顧客的價值。利用資料庫的資料，可以計算顧客生命周期的價值，以及顧客的價值周期。

（5）分析顧客需求行為。根據顧客的歷史資料不僅可以預測需求趨勢，還可以評估需求傾向的改變。

（6）市場調查和預測。資料庫為市場調查提供了豐富的資料，根據顧客的資料可以分析潛在的目標市場。

與傳統的資料庫營銷相比，網路資料庫營銷的獨特價值主要表現在三個方面：動態更新、顧客主動加入、改善顧客關系。

（1）動態更新

在傳統的資料庫營銷中，無論是獲取新的顧客資料，還是對顧客反應的跟蹤都需要較長的時間，而且反饋率通常較低，收集到的反饋信息還需要繁瑣的人工錄入，因而資料庫的更新效率很低，更新周期比較長，同時也造成了過期、無效數據記錄比例較高，資料庫維護成本相應也比較高。 網路資料庫營銷具有數據量大、易於修改、能實現動態數據更新、便於遠程維護等多種優點，還可以實現顧客資料的自我更新。網路資料庫的動態更新功能不僅節約了大量的時間和資金，同時也更加精確地實現了營銷定位，從而有助於改善營銷效果。

（2）顧客主動加入

僅靠現有顧客資料的資料庫是不夠的，除了對現有資料不斷更新維護之外，還需要不斷挖掘潛在顧客的資料，這項工作也是資料庫營銷策略的重要內容。在沒有藉助互聯網的情況下，尋找潛在顧客的信息一般比較難，要花很大代價，比如利用有獎銷售或者免費使用等機會要求顧客填寫某種包含有用信息的表格，不僅需要投入大量資金和人力，而且又受地理區域的限制，覆蓋的范圍非常有限。

在網路營銷環境中，顧客數據在增加要方便得多，而且往往是顧客自願加入網站的資料庫。最新的調查表明，為了獲得個性化服務或獲得有價值的信息，有超過50%的顧客願意提供自己的部分個人信息，這對於網路營銷人員來說，無疑是一個好消息。請求顧客加入資料庫的通常的做法是在網站設置一些表格，在要求顧客注冊為會員時填寫。但是，網上的信息很豐富，對顧客資源的爭奪也很激烈，顧客的要求是很挑剔的，並非什麼樣的表單都能引起顧客的注意和興趣，顧客希望得到真正的價值，但肯定不希望對個人利益造成損害，因此，需要從顧客的實際利益出發，合理地利用顧客的主動性來豐富和擴大顧客資料庫。在某種意義上，郵件列表可以認為是一種簡單的資料庫營銷，資料庫營銷同樣要遵循自願加入、自由退出的原則。

（3）改善顧客關系

顧客服務是一個企業能留住顧客的重要手段，在電子商務領域，顧客服務同樣是取得成功的最重要因素。一個優秀的顧客資料庫是網路營銷取得成功的重要保證。 在互聯網上，顧客希望得到更多個性化的服務，比如，顧客定製的信息接收方式和接收時間，顧客的興趣愛好、購物習慣等等都是網路資料庫的重要內容，根據顧客個人需求提供針對性的服務是網路資料庫營銷的基本職能，因此，網路資料庫營銷是改善顧客關系最有效的工具。

網路資料庫由於其種種獨特功能而在網路營銷中占據重要地位，網路資料庫營銷通常不是孤立的，應當從網站規劃階段開始考慮，列為網路營銷的重要內容，另外，資料庫營銷與個性化營銷、一對一營銷有著密切的關系，顧客資料庫資料是顧客服務和顧客關系管理的重要基礎。

資料庫的建立與管理

一、日益重要的資料庫

企業顧客的基本資料分別加以搜集、篩選、測試、整理、編集及充實之後，妥善儲存、保管。等到企業進行各種直復營銷活動之時，依照特定的目的需求，迅速且完整地提供相關個別顧客資料。現在，由於計算機技術發展得十分迅速，電腦在顧客資料庫的利用上，貢獻很大。

直復營銷是以目標顧客個人為對象，以雙向溝通的方式進行信息傳遞的，因此，慎重選擇目標顧客群，有系統地搜集目標顧客個別資料，進而形成顧客資料庫，並有效運用顧客數據，將是直復營銷成功的重要關鍵。

二、資料庫形成的六個階段

顧客資料庫從決定成立到向直復營銷人員提供信息，大致上有六個階段：

1、決定建立顧客資料庫 2、顧客資料的搜集 3、個別顧客資料卡的內容填寫 4、資料的整理及篩選 5、智慧型信息的完成 6、靈活使用顧客資料庫的信息。

資料庫營銷的前景

資料庫營銷縮短了商業企業與顧客之間的距離，有利於培養和識別顧客忠誠，與顧客建立長期關系，也為開發關系營銷和「一對一」營銷創造了條件。

（1） 以資料庫為基礎的顧客管理，為關系營銷奠定了基礎。

關系營銷強調與顧客之間建立長期的友好關系以獲取長期利益。實踐證明，進行顧客管理，培養顧客忠誠度，建立長期穩定的關系，對商業企業是十分重要的。資料庫營銷不僅受到沃爾瑪、麥德龍等傳統企業的重視，像亞馬遜這樣的新型網上企業更是十分重視客戶管理。比如，當客戶向亞馬遜買一本書以後，亞馬遜會自動記錄下顧客的電子郵箱地址、圖書類別，以後定期以電子郵件的形式向顧客推薦此類新書。這種方式極大推動了亞馬遜網上銷售業務的增長。

（2） 資料庫營銷，使商業企業能夠更詳細地了解顧客，增加了「一對一」營銷的可能。

「一對一」營銷是基於信息技術的發展提出的新的營銷理念，就是將市場細分到消費者個體，根據其消費習慣和需求特點提供個性服務。最近，在美國許多大城市出現一些「快速服裝店」，其目標顧客是有一定身份和地位的職業女性。她們或者工作很忙無暇購物，或者是厭煩挑選商品的煩瑣過程，但都需要不斷改變形象。服裝店便專門為這類顧客建立「一對一」檔案，從身高、體重、體形到氣質、職業、性格，都有詳細的記錄和分析。

Ⅵ 資料庫課程設計實例

資料庫課程設計

題目：小型超市管理系統
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、小結
和傳統管理模式相比較，使用本系統，毫無疑問會大大提高超市的運作效率，輔助提高超市的決策水平，管理水平，為降低經營成本， 提高效益，減少差錯，節省人力，減少顧客購物時間，增加客流量，提高顧客滿意度，增強超市擴張能力， 提供有效的技術保障。
由於開發者能力有限，加上時間倉促，本系統難免會出現一些不足之處，例如：
 本系統只適合小型超市使用，不能適合中大型超市使用；
 超市管理系統涉及范圍寬，要解決的問題多，功能復雜，實現困難，但由於限於時間，本系統只能做出其中的一部分功能；
對於以上出現的問題，我們深表歉意，如發現還有其它問題，希望老師批評指正。
請採納。

Ⅶ 簡述資料庫營銷的四個步驟是什麼

一、激活

新用戶的增量是衡量一個網站潛力的非常重要的因素。按照用戶的貢獻來計算的話，用比較粗暴的方式來算，就是：人均貢獻額=總的銷售額/總的消費人數=總的銷售額/總的注冊人數/注冊消費轉化率。

對一個穩定的網站，他的風格、商品價格、商品品質、引流渠道是一定的，基本就確定了網站的目標群體在哪裡。進一步看，網站內部的轉化率(從注冊激活，付款率，重復購買率)這些數據也基本都是穩定。除非你修改了一些購物流程，支付流程和商品陳列等東西，否則變化不會太大。基於這樣的假設，那你的總注冊人數就是個很關鍵的指標。(PS：如果你想不通，看看淘寶的注冊用戶增長和銷售增長的曲線，這就是用戶紅利。)

當用戶完成了注冊時，你就有了相關的聯系方式，一般的都是郵箱，有更清晰的會有電話。如果是社交類登陸的話，會更好，這樣的消息推送的成本低點。新注冊未產生銷售的用戶，一般的做法是用折扣信息來完成首單來完成。原因很簡單，有時候折扣可能會讓你首單虧本，但是你有了以下信息：用戶的聯系方式，具體收貨地址(很可能就是他的生活的地方，用作區域營銷用)，而更重要的是首單體驗，這個非常重要，就像走過一次的路，下次再走比較容易。而對整個購物流程來說，完成一次購買最復雜的地方是折扣。

二、催付

催付分兩個部分，一般的購物流程分選擇、支付兩塊：支付部分有的是從收藏開始，到購物車、到訂單，有的直接從未付款訂單開始。這個取決於自己的系統，只要記錄了相關的數據，對未付款訂單進行簡單的催付即可。(當然，如果你感覺真不夠可以送點福利過去)。催付只需要控制時間即可，比如1天、7天、30天進行催付，對應不同的策略，1天只是提醒、7天送積分、30天送現金券之類。

也可以對不同級別的用戶進行催付，用戶的分類就是累積消費金額較高、最近頻次比較多的、單個訂單金額較大的，這樣對應的催付可以設置不同的現金券。催付的渠道也可以設置，比如利用聊天軟體、簡訊、郵箱、我的賬戶完成。

購物車的部分是快速生成訂單並完成支付，用相關的折扣券效果比較好，還可以利用恐嚇式營銷。比如購物車商品的提價，針對那些購買了一些特價商品的。比如下架，當有些商品庫存較少時，提醒就要下架，馬上要其付款。

還有個部分是是收藏列表，收藏列表一般的作用是什麼?無外乎幾點，1.關注的商品，想要的。2.比較，已經大體的方向，選幾個商品進行比較價格，款式等。從這個裡面大體可以分出幾個點：類目偏好，價格偏好。有了這些點，可以做一個很牛的動作，對收藏比較多的某類、某個商品做整體促銷，設計價格折扣，然後再根據目標人群再進行相關的調整。

三、分類

購買過1單的用戶已經對你的網站有了基本的了解。從網站購物，到支付、收貨，及相關商品的質量，有了初始印象，就可以進行相關的用戶分群營銷了。基本的用戶群可以分成以下幾種:

1.類目偏好。或者更准確的說是商品偏好，這個用戶只在你這個網站賣的商品，比如我比較喜歡在淘寶買小玩意，在當當買書，在米蘭網買服裝，每個人對每個網站買什麼一般都有固定的偏好。特別是經常網上購物的。可以從網站瀏覽的商品、收藏、購物車、購買的商品就基本可以分析出來。

2.價格偏好。從類目的價格分布和購買、點擊的商品的價格進行對比，基本能分析出用戶的價格偏好。還有使用折扣券的情況，積分的情況，這是利用現有折扣進行的。例如，如果有人對商品價格敏感的，就完全可以使用運費的費用調節;再比如，運費是服務范疇，而商品是實物范疇，有很多人喜歡付10塊錢的運費買20塊的商品，這是買服務。而你直接30塊包郵的話，他就感覺貴了。這些需要一些價格的AB測試，目的是測試用戶看重的是商品，還是服務。

3.節假日偏好。這種偏好的人是比較懶的。節假日偏好只所以產生是無外乎幾點：1.節假日會做一些打折，往往折扣力度比較大。2.商家會把相關的商品按照各種主題准備好，然後劃分各個類型。有了這兩點，商品好找，又打折，自然有很多懶人在等待。這種人往往是前兩種的結合體，而剛好節假日滿足了它們的訴求，所以有了這樣的群體。可是商家慣用的伎倆就是提價打折，尾貨處理等。運氣好可能碰到商家是用流行品做引流做活動的。

四、挽留

挽留是指原來購買的用戶不再購買了，對用戶進行的挽留式營銷。一般會有1月，3月，6月的做法，不同的品類和平台對應的時間不同，換句話說就是不同的類目和平台的用戶生命周期不一樣。類似淘寶服裝類的女性用戶一般會比淘寶服裝的男用戶活躍，1個月不登陸女性用戶可能就流失了，男性用戶可能是正常的。所以，這個可以根據平台和類目的屬性進行考慮。

我們可以設定一個大概的閾值，當超過了某個設定值後，就要做挽留措施了。挽留措施一般是推薦新品、積分使用、折扣券提醒、相關的挽留活動。對於那些平台數量比較大的，可以設置挽留用戶的專區進行營銷，主要方式是不同分群的用戶，用對應的高質量的商品進行吸引，然後利用對應的折扣、服務等去換回，這樣會比較精準。

還有比較犀利的做法是積分直接兌換現金券進行消費，積分到消費比較遠，如果直接兌換現金券，會讓人覺得變現，而增加粘性。想想微信紅包，直接發紅包導致了幾百萬的銀行卡綁定，還是說明有這樣的心理的人是很多的。

Ⅷ 關於電商網站資料庫的設計有什麼好的建議

這個問題的核心點在於：不同商品類別差異很大，如何設計通用的存儲方案？簡單來說，用資料庫去存儲所有信息，不管橫表還是縱表，都有明顯的缺陷：橫表：同一個欄位對不同商品含義不一樣，這到了後面開發和維護是很蛋疼的縱表：一個商品的屬性分布到很多行記錄中，業務處理很麻煩，而且縱表的記錄數會非常多，性能會有問題所以不要嘗試只用資料庫去統一解決這個問題，思路擴散一些其實就簡單了：公共表：提煉商品公共的信息放到資料庫，例如商品id、名稱、發布的商家、發布日期、上架狀態擴展表：將變化的信息放到另外一個表，可以是資料庫表，例如電腦商品一個表、服裝一個表；也可以將信息放到MongoDB或者ElasticSearch這類文檔資料庫。搜索組件：擴展表在全文搜索的時候不好實現，因此需要獨立的組件負責搜索，可以用Elastic Search或者Solr來冗餘一份數據，用於搜索。表結構不算復雜，因為項目關系只有SPU，沒有涉及到SKU，但是可以做參考，更多的還是要根據項目實際情況設計。重點說明一下產品表的SPU，Keyword欄位。本來之前設計了關系表，但是發現在做SQL查詢時太痛苦，所以約定了一種數據存儲結構（數據結構的重要性）基於上面的基礎，可以實現URL規則變化的查詢,類似京東的產品查詢URL變化c=1,3 指分類層次關系ev=3_1+4_18 指SPU查詢 按約定規則轉換成字元串再進行查詢。

Ⅸ 請教有電子商務（網上商城）設計經驗的高手，關於促銷策略資料庫設計

我給企業做過許多電子商務網站，活動促銷是每個網上商城必須有的，我就講下，我對活動促銷的開發設計方法吧。
我的促銷方式有：全場免郵費或滿額免郵費、分層級滿額贈禮品、限時折扣促銷、買就贈等
首先要明確每種活動的性質：
1、全場免郵費或滿額免郵費，滿額贈禮品、買就贈（訂單）等這種形式是一種訂單活動；
2、限時折扣、打折促銷、買1贈1、買就贈（單品）等形式是單品活動；
那有上面兩種形式後我們就容易來處理了，訂單活動，我們只需要建設一個資料庫表設置活動的形式及滿額的額度還有分級及禮品就可以了，然後客戶下訂單後，我們從訂單裡面來處理這個活動；
第二種單品活動，我們就要從單品上來處理，兩種形式，1直接從產品表裡面設置，前台讀取後判斷設置該產品是否活動開啟；2單獨創建活動表，設置活動形式，產品編號等相關信息欄位，然後從活動頁面讀取這些信息即可。
我不知道我的回答是不是滿足你的需求，我們可以多溝通下。