電子商務系統資料庫設計

Ⅰ 分析電子商務中的數據安全論文

在學習和工作中，大家都不可避免地要接觸到論文吧，論文是進行各個學術領域研究和描述學術研究成果的一種說理文章。如何寫一篇有思想、有文採的論文呢？下面是我整理的分析電子商務中的數據安全論文，歡迎大家分享。

分析電子商務中的數據安全論文 篇1

一、引言

電子商務信息系統中存放著大量機密敏感的數據，這些數據是電子商務企業運營時重要的信息。

這些數據如果存在安全問題， 就會給企業經營帶來很大風險。

本文將對電子商務系統的數據安全進行討論，從而為提升其安全技術與管理水平給出一些合理的建議與策略。

二、電子商務資料庫與其安全問題

1、電子商務數據安全概述

電子商務數據安全的具體含義為：保證電子商務資料庫信息的保密性、完整性、一致性、可用性和抗否認性。

保密性指保護資料庫中的數據不被泄露和未授權的獲取：完整性指保護資料庫中的數據不被破壞和刪除；一致性指的是確保資料庫中的數據滿足實體完整性、參照完整性和用戶定義完整性要求；可用性指的是確保資料庫中的數據不因人為或自然的原因對授權用戶不再可用；抗否認性是保證用戶事後無法否認對資料庫進行的一系列訪問、修改、查詢等操作，便於事後分析調查。

2、電子商務資料庫面臨的安全威脅

（1）黑客攻擊。

網路中總是存在各種安全漏洞，因此黑客的攻擊行為是威脅電子商務數據安全的一大隱患。

黑客攻擊網路的目的通常是擾亂系統正常運行或者竊取重要的商業機密。

黑客慣常使用的攻擊手段為：竊—即黑客通過截獲通訊信道上的重要數據並破譯來達到竊取用戶機密的目的；重發攻擊—黑客為達到影響系統正常運行的目的，而將竊得到的數據經過篡改之後重新發回伺服器或者資料庫用戶；迂迴攻擊—黑客掌握電子商務資料庫系統的安全漏洞之後，繞過資料庫系統而直接訪問機密數據；假冒攻擊—黑客先是採取發送大量無意義的報文而堵塞伺服器和客戶終端的通訊埠以後，再通過假冒該客戶或者該伺服器的方法來非法操作資料庫系統；越權攻擊—黑客屬於一個合法用戶，但是其通過某種手段使自己去訪問沒有得到授權的數據。

（2）系統漏洞。

針對於電子商務資料庫系統的網路入侵者能夠根據系統本身的安全漏洞得到系統的數據操作許可權。

漏洞產生的原因往往是資料庫管理系統沒有及時打補丁或者在安全方面的設置中總是選擇默認設置。

此外，如果由於資料庫的安全檢查措施級別太低，或者審核機制應用不當、軟體存在的風險以及管理風險等，都會使系統形成安全漏洞，從而給破壞者以入侵的機會。

三、電子商務數據安全解決方案

1、加密方案

電子商務系統中的一些商業機密數據是不允許普通用戶進行隨意訪問的。

加密方案的目的是控制以上這些機密數據只能被得到相應授權的`特定人群所訪問和存取。

資料庫管理系統的加密以欄位為最小單位進行，加密和解密通常是通過對稱密碼機制的密鑰來實現。

數據加密時，資料庫管理系統把明文數據經過密鑰轉換為密文數據，資料庫中數據的存儲狀態都是密文數據，而在得到許可權的用戶查詢時，再將密文數據取出並解密，從而恢復明文數據。

使資料庫的安全性得到進一步提升。

2、訪問控制方案

在資料庫管理系統中，不同的用戶擁有不同的許可權。

因此必須保證某個用戶只能訪問或者存取與自己許可權相應的數據范圍。

用戶所擁有的許可權包括兩方面的內容：一是用戶可以訪問資料庫中什麼樣的數據對象，二是用戶可以對這些數據對象進行什麼樣的操作。

當用戶對資料庫進行訪問時，系統會根據用戶的級別與許可權來判定此種操作是允許的或者禁止的，從而達到保護敏感數據不被泄露或者篡改的目的。

訪問控制方案有三種，分別叫做自主存取控制（Discretionary Access Control， DAC） 、強制存取控制（Mandatory Access Control， MAC） 和基於角色的存取控制（Role— based Access Control， RBAC）。

3、認證方案

身份認證技術是資料庫管理系統為防止各種假冒攻擊安全策略。

在用戶對敏感關鍵的數據進行存取時，必須在客戶與資料庫管理系統之間進行身份認證。

口令的識別是資料庫管理系統進行身份認證的一種方式，每個具體用戶都被系統事先分配一個固定的用戶名與密碼，電子商務系統的許多數據具有開放性特徵，因此必須對每個訪問系統的用戶的身份進行認證，這樣就可以阻止不擁有系統授權的用戶非法破壞敏感機密的數據。

4、審計方案

審計方案是資料庫管理系統對相關用戶的所有操作過程進行監視的一種安全方案，該安全方案的具體做法是在審計日誌記錄中存放各用戶對資料庫施加的動作，包括用戶的修改、查詢和刪除等操作。

這種有效機制可以在最大程度上保證資料庫管理系統的信息安全。

有兩種審計方式：分別叫做用戶審計和系統審計。

用戶啟用審計功能將在數據字典中記錄每個用戶操作資料庫的全部細節，包括用戶名稱，操作類型等等；而系統審計則由DBA來進行。

5、備份方案

可以把電子商務資料庫的故障或障礙分為以下三類： 系統故障、事務故障以及介質故障。

當發生某種類型的故障時，為了把企業的損失減少到最低，必須在最短的時間內恢復數據，因此，根據企業的實際情況和數據類型與特點，制定出一套合理而經濟的備份和恢復策略是必要的。

所謂資料庫備份與恢復方案，目的是在資料庫系統故障並且短時間內難以恢復時，用存儲在備份介質中的數據將資料庫還原到備份時的狀態。

數據備份根據資料庫管理系統類型的不同， 有多種備份實施計劃。

比如對sql Server而言，有資料庫備份、事務日誌備份、增量備份和文件及文件組備份。

電子商務信息系統的資料庫管理系統中必須建立詳細的備份與恢復策略。

四、結束語

對電子商務企業來說 ，數據安全的重要性是無庸諱言的。在對機密敏感數據的管理時，必須根據應用環境的具體安全需要來實施各種安全策略。

分析電子商務中的數據安全論文 篇2

[摘要]

酒店電子商務不僅可以為顧客帶來方便，也可以為酒店帶來經濟效益和先進管理。本文對酒店電子商務的應用現狀、優勢、解決方案、發展過程中存在的問題進行了研究，對其可能出現的發展趨勢進行了討論。

[關鍵詞]

酒店；電子商務；優勢；應用發展

電子商務是20世紀信息化、網路化的產物。近幾年來，隨著知識經濟的發展和信息高速公路的建設，電子商務在互聯網上開展起來。電子商務以其難以想像的發展速度成為酒店最有效、最經濟、最便捷的營銷手段。有些酒店每天通過類似Ctrip，E-long等網路訂房中心的預定有時甚至超過了前台的散客。酒店網路銷售系統是具有革命性的酒店營銷創新。它的優勢主要在於有效展示酒店形象和服務，建立與客戶良好的互動關系，具有高效管理銷售過程，且顯著降低銷售成本、提高經濟效益和管理水平。

一、酒店業電子商務的需求

電子商務平台在酒店業中的應用，要根據市場空間大小來確定市場可行性。根據《中國旅遊統計年鑒》(2005年)顯示：2004年全國星級飯店(按經濟類型、規模和星級分)共計10888家，其中五星級242家，四星級971家，三星級3914家，二星級5096家。2004年，全年營業收入總額為1238．67億元，上繳營業稅71.07億元。另外，根據數據顯示，中國旅遊市場目前的規模約為6000億元人民幣。並且預計未來幾年內保持持續增長。這個市場規模之大，足以吸引酒店通過建立完善的電子商務體系來促進酒店的業務發展。

隨著國際旅遊酒店業電子商務市場發展勢頭的迅猛，酒店網上銷售額幾乎占據在線旅遊行業的三分之一，但由於網上支付安全性和信任性問題，目前真正網上支付的客人仍然很少，要實現真正意義上的網路銷售還有待時日。盡管如此，現今國內銷售酒店客房的專業網站為數已不少，許多酒店還進入了國內各種旅遊商務網站和國外相關網站。

二、酒店電子商務優勢

酒店電子商務的開展首先給酒店業經營增加了新的服務產品，滿足了市場的新變化。因為遊客，特別是商務客人，他們需要在旅途期間仍然得到互聯網服務，於是電子商務的開展使得酒店增加了對客服務的內容，為客人帶來了方便。

酒店通過互聯網來采購設備，可以方便地實現規模采購和享受熟客優惠。對於數額較大的采購項目，一般就可以採用優先決策方式，做好管理控制。電子商務的開展提供了售前、售中和售後的全過程服務，包括從酒店需求設計的配置計劃制訂、價格查詢、預定、支付、配送等所有環節，可以為酒店節約大量的人力，財力和物力成本。

三、酒店電子商務建設解決方案

1.總體方案設計審核

酒店電子商務建設是一個系統工程，為了當前項目所需而不顧日後發展的方案，不僅造成重復投資而導致浪費，若方案不符合業務需求還會降低項目本身的實際功效。因而，酒店電子商務建設應該量身定做，提出總體設計方案，並由行業管理部門組成專家組，對總體方案進行論證和審核，以確保方案的先進行、可行性。

2.建立行業認證

有的IT公司並不了解酒店業的特性，並在客房寬頻合同中明確規定了網路環境產權不屬於酒店。因此，酒店無權在該網路環境加設任何其他應用項目。鑒於上面提及的問題，有必要針對那些專業從事酒店業電子商務建設方案實施的企業進行認證，以確保從事酒店電子商務建設的IT公司都具有專業性，避免酒店電子商務建設走彎路。

3.建立服務標准

對於酒店而言，電子商務是一個工具、一種手段、一種服務，服務水平的高低直接影響到酒店經濟效益和競爭力。雖然目前我國高級技術人才輩出，卻大多投身於高薪技術領域，而在服務行業出現斷層現象。這也就成為酒店開展電子商務中的一大瓶頸。

四、酒店電子商務發展與展望

未來的酒店電子商務應向增強與客戶的雙向交流、改善信息服務、通過個性化服務增加附加值的方向發展，目前我國酒店電子商務「以交易為中心」色彩較濃，預計未來酒店電子商務將在服務上更加完善，更加人性化。

1.電子商務的規范化與標准化

酒店電子商務是一個新興領域，我國在酒店電子商務規范與標準的整體制定和推行方面尚非常薄弱，這應是下一階段發展的重點。

首先是規范化，建立健全酒店電子商務規范體系，為酒店電子商務的實施和監管、企業和消費者的市場行為、信息內容和流程、技術產品和服務等提供指導與約束，預先對那些可能對酒店電子商務活動產生不利影響的潛在因素加以防範。

其次是標准化。在國外，通常是由專門的組織（如OTA）制訂出一套統一的數據格式和介面標准，酒店電子商務網站、管理信息系統在開發時都遵守這套標准，這樣在一開始就能夠保證與酒店的信息系統做無縫鏈接的可能性。我國酒店電子商務的數據應該盡快實現標准化，與國際接軌。

2.移動電子商務將成為主流

移動電子商務結合智能網路技術，是真正實現以人為中心的電子商務應用。如移動支付—顧客無論在何時何地，通過行動電話等終端就能完成對企業或對個人的安全的資金地付。新技術的應用將使酒店電子商務功能更加完善，應用更加普及。

五、結束語

進入21世紀，電子商務充滿活力、飛速向前發展，電子商務使整個市場、各個行業發生著驚人的變化，酒店業也不例外。以無線網際網路為載體的第三代電子商務模式正在蓬勃發展中。我們迫切希望電子商務為酒店業的發展發揮橋梁紐帶作用，希望酒店電子商務得到健康有序的發展。

參考文獻：

[1]董志文張軍：對酒店計算機信息管理系統的分析與展望．海岸工程，2002，(2)

[2]巫寧：旅遊電子商務理論與實務[M]．北京：中國旅遊出版社，2003

[3]王振侯功顯：我國酒店電子商務體系構建研究[J]．湖北經濟學報，2007，(12)

[4]李琪：電子商務通鑒[M].北京：中國商業出版社，2000

Ⅱ 如何設計電子商務網站的資料庫並E-R圖

先進行了解需求，分析其中的實體和關系，再用資料庫建模工具比如powerdesigner，進行繪制er圖

Ⅲ 電子商務 服裝系統資料庫怎麼設計

上淘寶上那些賣家，他們會知道的，不過可能需要收費的。嘿嘿，這個問題太專業了

Ⅳ 電子商務網站一般架構有哪些

大型電子商務網站架構，摘抄 7.同一個網站的多語言該如何處理是好,使用配置文件然後cookie或url來判別?===客戶是自己公司，使用標准方法即可
8.電子商務網站最多的就是 商品的打折方式和積分的贈送了,這里要怎麼設計才好(工廠模式)?===采購成熟的規則引擎
9.如果同一時間並發大量訂單的話,如果確保一個訂單的有效提交呢?
==電子商務一般要使用MQ，推薦IBM MQ；使用MSMQ也可
第一點是資料庫要設計好，要達到什麼級別，你可能需要考慮哪些表需要拆分，哪些表的核心數據需要冗餘，如果是mysql，還要考慮其他的問題，比如存儲引擎。
新聞肯定是要生成純靜態頁，對資料庫壓力就小很多，不過靜態頁也有管理上的不方便，更新刪除添加都要對磁碟文件進行操作
做一個自定義緩存層，對緩存邏輯進行控制，可以採用第三方緩存模塊，如果使用.net來做，可以層層緩存，頁面緩存，數據緩存（memcache，不過在win下效率不高）
電子商務網站特點就是對事務的嚴格，需要資料庫設計的時候要求高性能，也需要合適的索引，支持高並發，經常對產品表用戶表等進行索引檢查，是否有很多索引掃描和表掃描（即使是局部的，也要將「局部」控制到最小范圍）
mssql語句對不需要事務的查詢要附帶上with(nolock),以利於並發更新。
有些功能模塊不能按照想當然的方式開發，比如產品訪問次數，切不可將這些更新非常頻繁的欄位置於核心表內，明確的做法是將其剝離開來 還有就是切不可經常性將欄位設計成bool類型，這樣會給以後的擴展留出路，即使是男女這種欄位，也建議採用tiny類型
其他還有就是在產品設計的時候充分考慮seo，網站目錄結構清晰可讀，而不是帶著一串串的查詢參數。
對安全要有整體的把握，最好全都是用存儲過程，在項目上線前將資料庫存儲過程全部導出再查找貌似exec的語句，查找是否需要替換成sp_executesql。
另外，如果採用mssql，全文搜索直接用mssql fte就可以，速度和精確度都還是可以的，最重要的是維護和管理開發很簡單。
打折的處理可以按照電信的一次，二次批價功能，如果你做過電信方面的系統。
當然也可以設計得更簡單的一些。 靜態的頁面建議使用CDN加速，以解決網通和電信之間訪問速度的問題；
數據的緩存方面建議考慮用memcache，另外也可以分別在表現層和數據層利用.net中的現存緩存機製作業可；
簡單執行的sql可以不用存儲過程，存儲過程會佔用資料庫伺服器的處理時間，造成死鎖；
mvc建議還是做些CMS的項目上應用，電子商城不是很適合，個人觀點。url上可以做轉義，使url顯示更友好；
資料庫建議建立分布資料庫，這樣可以轉移查詢和大訪問量對資料庫帶來壓力；
圖片可以考慮單獨放在一台伺服器上；1.三層架構
2.使用手寫sql,手寫entity(生成也可),緩存反射綁定(不是緩存數據哦,緩存映射關系),要考慮網站的長期發展還是手寫吧 靈活 性能也好
3.沒有這種問題,商業驅動的,純購物就好了,千萬別搞什麼圈子,wiki
4.純.net的mvc不建議,webform不搞viewstate,不搞服務端控制項(除repeater)再加點mvc的思想已足夠用了
5.不需要緩存數據(除搜索產品部分),要考慮多台伺服器的程序快速部署,config文件會很多,config要序列化緩存
6.當然是先生成好了,參照jd吧,按業務每張圖片對應幾個不同大小的圖
7.據經驗,電子商務網站僅靠中英雙語來達到多語言是不靠譜的(文化 用戶習慣不是簡單的語言切換),如果想真正運營英語的就要重新開發一個版本
8.不搞模式
9.負載均衡(web,db)+ssb非同步處理數據
10.你是業務類型的日誌還是異常日誌? 前台訂單流程上異常日誌不需要了,找個工具錄個腳本不停的跑 保證隨時發現問題發郵件就可以了
11.找第三方搜索組件 類似endeca的
12.負載均衡挺簡單的,初期靠軟體就可以,一切圖片找第三方放cdn,前台網站用到ajax的地方很少,如果用的話jquery 1，一個電子商務網站用戶99.5%的行為時Find
2、對於商品檢索部分，能不用資料庫就不用資料庫（網上切詞等相關的開源平台很多）
3、分布式緩存（Memcached 、Volecity），個人測試volecity 3還是不錯的
4、系統設計時必須要考慮可運營。從這個角度去設計系統
5、對於電子商務網站改動很頻繁，必須考慮架構設計如何適應頻繁的版本更新
6、必須設計一個好的單點登錄系統。
7、建議能不用sqlserver就不用它。
8、對於大型電子商務網站來說，系統的I/O是起決定因素而不是CPU和內存。1.項目劃分是否會有問題,圖中分別是 實體層,數據訪問介面層,數據訪問層,業務邏輯介面層,業務邏輯,網站A,B,C
項目劃分其實不重要，重要的的是你在寫代碼的時候是否能把代碼合理的分到對應的項目里。
2.數據訪問層是要開發效率(NBear,Linq,Nh等),還是訪問效率(直接使用sql等)?是否可以先使用開發效率高的,等日後訪問量大了,再重寫並替換數據訪問層?
開發效率優先，訪問量大了以後，我相信是有錢投到硬體上的，在你程序寫的不是很爛的情況下，升級硬體遠比優化程序節省成本。
3.網站被切割成了多個子網站,有一些控制項(如header,footer)是要共享的,如何跨網站項目共享這些控制項呢?
那就做成自定義控制項啦。
4.ms的mvc 1.0也出來不少時間了,是否已經夠成熟運用到項目中?或者是網站後台使用webform的,前台使用mvc?
推薦使用使用webform的,前台使用mvc，對於前台來說使用mvc能更好的提升性能，更方便的更換頁面表現形式。後台界面相對穩定，用webform可以提高開發效率。
5.網站數據的緩存是自己開發一個hashtable什麼的來維護呢,還是使用Memcached ?
初期建議用hashtable，因為簡單，將來升級到Memcached 。
6.縮略圖的處理,我看有的網站是在上傳圖片的時候直接生成,有的是在httpmodle里處理,訪問的時候生成.
直接生成縮略圖的好處是節約性能。httpmodle相反，每次瀏覽圖片的時候都會生成新的圖片，伺服器壓力大，建議直接生成。
7.同一個網站的多語言該如何處理是好,使用配置文件然後cookie或url來判別?
多語言建議使用asp.net自帶的資源文件的方式實現，當前語言保存在cookie裡面。
8.電子商務網站最多的就是 商品的打折方式和積分的贈送了,這里要怎麼設計才好(工廠模式)?
規則引擎
9.如果同一時間並發大量訂單的話,如果確保一個訂單的有效提交呢?
使用MQ隊列
10.日誌方面,log4net?
log4net只能記錄程序運行日誌，主要目的是用來調試程序的，系統業務操作日誌還你是得自己建一個表來保存。
11.電子商務的全文檢索,這也是個頭疼的問題
lucene，微軟索引服務，sqlserver全文檢索，方案很多的。
12.負載均衡方面,有什麼好的文章推薦碼?
可以看windows 2003 集群方面的文章 1.項目劃分是否會有問題,圖中分別是 實體層,數據訪問介面層,數據訪問層,業務邏輯介面層,業務邏輯,網站A,B,C
目前我也是這樣分的,不過當數據表結構有修改時,會帶動其它層的聯級修改,非常不方便，所以開發之前最好將資料庫設計地完善一點。另外，當網站分成多個以後，其它項目生成的DLL文件要部署到每個網站的bin文件夾里，更新一次都要重新部署，這也是個挺煩人的事，當然可以將DLL部署到GAC里來解決這個問題，不過這樣的話本地調試起來就不太方便了，因為項目一有改動，就要將生成的DLL重新拷貝到GAC里才能看到效果。
2.數據訪問層是要開發效率(NBear,Linq,Nh等),還是訪問效率(直接使用sql等)?是否可以先使用開發效率高的,等日後訪問量大了,再重寫並替換數據訪問層?
這個我也在考慮。目前我還沒有採用ORM框架，都是在DAL里直接訪問DB的。
3.網站被切割成了多個子網站,有一些控制項(如header,footer)是要共享的,如何跨網站項目共享這些控制項呢?
自定義控制項。
4.ms的mvc 1.0也出來不少時間了,是否已經夠成熟運用到項目中?或者是網站後台使用webform的,前台使用mvc?
正在學習這一塊。
5.網站數據的緩存是自己開發一個hashtable什麼的來維護呢,還是使用Memcached ?
現在我用的比較多的是.net自帶的數據緩存。
6.縮略圖的處理,我看有的網站是在上傳圖片的時候直接生成,有的是在httpmodle里處理,訪問的時候生成.
直接生成好，快一點。
7.同一個網站的多語言該如何處理是好,使用配置文件然後cookie或url來判別?
我沒涉及到這一塊，不過我覺得資源文件應該就是用來處理這個問題的。
8.電子商務網站最多的就是 商品的打折方式和積分的贈送了,這里要怎麼設計才好(工廠模式)?
這些都放在邏輯層好了。
9.如果同一時間並發大量訂單的話,如果確保一個訂單的有效提交呢?
MSMQ
10.日誌方面,log4net?
目前我是自已寫代碼存在庫里的。
11.電子商務的全文檢索,這也是個頭疼的問題
用lucene.net分詞建索引，再直接從索引庫里搜索，又快又准。
12.負載均衡方面,有什麼好的文章推薦碼?
不清楚了。 這樣的設計要達到新蛋的效果肯定不可能的，新蛋少說幾百台伺服器，不同資料庫之間的發布訂閱鏈路都有幾千條。有復雜的緩存，負載均衡機制。新蛋所有的通訊都是基於WCF的。另外對於這么大型的網站來說，資料庫一刻都不停止，所以讀寫分離也很重要，因為你也不可能讓資料庫停下來進行備份。總歸要做到新蛋這樣的大型電子商務網站，靠你上面畫的這點好像遠遠不夠。
不過關於公共的header,footer,我不建議做成自定義控制項，這個維護起來不方便，稍有變動就要發布dll，麻煩的。
如果你的header和footer不是很大的話，建議採用js+css的方式。然後加上壓縮和cdn緩存，應該效率上能接受。

Ⅳ 電子商務網站資料庫設計時，商品表如何設計的問題

你開始並沒有說清楚
按你的最新要求，應該是：
一個商品表，一個屬性表（欄位不重復了）
然後就是賣家商品表，欄位如下：
賣家id 商品id 商品數量
明白嗎？

如果多個店賣同一種商品，那數據都在賣家商品表裡
需要商品名時，從商品表關聯取數據，
需要商品屬性時，從屬性表關聯

你想的復雜了
就2個表，一個商品表，一個屬性表
商品表欄位：id 品名
屬性表欄位：商品id 屬性名 屬性值

也就是說一個屬性一條記錄

Ⅵ 電子商務與資料庫應用課程設計（急，求助~）

一個簡單教務管理系統的數據建模

Ⅶ 電子商務網站資料庫設計

洗衣機和筆記本因為屬性差別比較大，如果只建一個表的話，冗餘的信息太多，不符合範式的要求。
可以為同一類產品建一個，比如電子產品作為一個實體包括（筆記本，MP4，手機，照相機等等），因為電子產品的屬性比較相似，該實體的屬性有產品編號，名稱，尺寸，處理器，存儲器，屏幕尺寸等等。這要做既可以減少表的數量，又不會顯得數據過於冗餘。
所以要不要把數據放在一個表裡就要看你選擇的諸多實體是否有很多相同的屬性。當然沒有任何相同屬性的實體也是可以放在一個表裡的，那樣只會導致很多數據出現空值，也不會出現多大錯誤，數據查找會變得很慢而已，不能體現良好的設計思路。

Ⅷ 電子商務系統分析與設計怎麼進行資料庫設計

(1)需求分析，形成用戶需求規約、索引結構和數據的存放次序與位邏輯等)，即用戶要描述的現實世界的概念數據模型，通過對其中住處的分類。一般，第一步先明確現實世界各部門所含的各種實體及其屬性，運行一些典型的應用任務來驗證資料庫設計的正確性和合理性。

(2)概念設計。第二步再將前面得到的多個用戶的局部視圖集成為一個全局視圖，即適應於某種特定資料庫管理系統所支持的邏輯數據模式。因此、一個商場或者一個學校等)、實體間的聯系以及對信息的制約條件等，可能就需要返回到前面去進行修改，在做上述資料庫設計時就應考慮到今後修改設計的可能性和方便性.

(3)邏輯設計、聚集和概括、信息間的互相制約關系以及各部門對信息儲存。

(5)驗證設計，建立抽象的概念數據模型，資料庫的設計過程大致可分資料庫設計為5個步驟;根據特定資料庫管理系統所提供的多種存儲結構和存取方法等依賴於具體計算機結構的各項物理設計措施、范圍。

(4)物理設計。當設計的某步發現問題時、存取方法和存取路徑等;對用戶要求描述的現實世界(可能是一個工廠，可能還需為各種數據處理應用領域產生相應的邏輯子模式、信息流動情況，弄清所用數據的種類。這個概念模型應反映現實世界各部門的信息結構，一個大型資料庫的設計過程往往需要經過多次循環反復;主要工作是將現實世界的概念數據模型設計成資料庫的一種邏輯模式：

Ⅸ 求一個電子商務資料庫設計步驟

一般，資料庫的設計過程大致可分資料庫設計為5個步驟：
(1)需求分析；調查和分析用戶的業務活動和數據的使用情況，弄清所用數據的種類、范圍、數量以及它們在業務活動中交流的情況，確定用戶對資料庫系統的使用要求和各種約束條件等，形成用戶需求規約。
(2)概念設計；對用戶要求描述的現實世界(可能是一個工廠、一個商場或者一個學校等)，通過對其中住處的分類、聚集和概括，建立抽象的概念數據模型。這個概念模型應反映現實世界各部門的信息結構、信息流動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求等。所建立的模型應避開資料庫在計算機上的具體實現細節，用一種抽象的形式表示出來。以擴充的實體——聯系模型方法為例，第一步先明確現實世界各部門所含的各種實體及其屬性、實體間的聯系以及對信息的制約條件等，從而給出各部門內所用信息的局部描述(在資料庫中稱為用戶的局部視圖)。第二步再將前面得到的多個用戶的局部視圖集成為一個全局視圖，即用戶要描述的現實世界的概念數據模型。
(3)邏輯設計；主要工作是將現實世界的概念數據模型設計成資料庫的一種邏輯模式，即適應於某種特定資料庫管理系統所支持的邏輯數據模式。與此同時，可能還需為各種數據處理應用領域產生相應的邏輯子模式。這一步設計的結果就是所謂「邏輯資料庫」。
(4)物理設計；根據特定資料庫管理系統所提供的多種存儲結構和存取方法等依賴於具體計算機結構的各項物理設計措施，對具體的應用任務選定最合適的物理存儲結構(包括文件類型、索引結構和數據的存放次序與位邏輯等)、存取方法和存取路徑等。這一步設計的結果就是所謂「物理資料庫」。
(5)驗證設計；在上述設計的基礎上，收集數據並具體建立一個資料庫，運行一些典型的應用任務來驗證資料庫設計的正確性和合理性。一般，一個大型資料庫的設計過程往往需要經過多次循環反復。當設計的某步發現問題時，可能就需要返回到前面去進行修改。因此，在做上述資料庫設計時就應考慮到今後修改設計的可能性和方便性。