数据库表间关系管理原理

公司的网站www.studyez.com 在实际开发过程中，经常要对数据库进行操作，搞来搞去常用的也就哪么几种。所以就想把数据库的操作进行一些封装。记得在那本书或是杂志上看到某个牛人这样评价数据库的设计“键，键，键，除了键还是键”，其它的什么一二三范式什么的，在学校里老师也讲过。不过看来看出，也没脱离三种关系。

就是”一对一，一对多，多对多“三种关系，再复杂的关系也不过是在上面多转了几圈而已。

后来又抽空了看了些敏捷开发，设计模式之类的书。在网上也找了不少ORM方面的源码看过。搞了半天也就是在三种关系的处理上面应用了反射等一些新东东。可是用起来还是感觉怪怪的。下面我个人的一些看法，欢迎各位老兄指点。但是请不要说脏话。

------------------------------基本原理-----------------------------

1:数据访问的基本行为.

a)存储。-------将数据保存在持久性存储介质之中。

b)读取。-------根据唯一标识符从存储介质中读取数据.

c)删除。-------从持久存储介质当中删除数据及其关联数据《保持数据的完整性》

 d)编辑。-------根据唯一标识符修改特定数据的部分可编辑属性。

 

e)计数。-------计算持久存储介质中符合某些特定条件的数据记录总数。

f)分页。-------显示符合某一特定条件下的一部分数据。

 

-------------说明----------------------------------

一）e ,f是成对出现的。

二）数据本身只具a,b,c,d四种的某一种或多种的行为。

三）e,f是数据编组行为同时又是b行为的扩展或是b是ef的浓缩，主要是为了提高数据读取的性能。

-----------------------------------------------------------------------------

 

2:不同数据实体之间存着三种对应关系。

      夫妻关系《1：1，一夫一妻制,一夫多妻就不考虑了啊。》

          可以表示为：M:{N} 或 N:{M}

行为有:离婚.T(M.Hasband=N and N.Wife=M )

         结婚.T(M.Hasbank=Null and N.Wife=Null )

-----------Hasbank 好象是拼错，大致是这样拉的吧。

角色:夫(r1)，妻。(r2)

限制

[

一）不许重婚

二）双方必须同时存在

]

     父子关系《1:N，一个人有0到K个儿子（K<N)》

         可以表示为：M:{S0,…,SK} [0<=i<=K]

         行为有：生子认父 T( M.Sons.Add(Si) and Si.Parent=M )

                   断绝父子关系:T( M.Sons.Remove(i) and Si.Parent=Null and Si.Delete() )

         ------------------------------------------

         角色:父(r1)，子(r2)

         限制

[

一）先生后认，

二）可以无子但不可以无父

]

     伙伴关系《M：N，每个人都有数目不等的平等伙伴》

其中 M：N是1:N的扩展。M：N

可以表示为：M1:{N0,…,NK}

                M2:{N0,…,NK}

                …

                MM:{N0,…NK}

              

                N0:{M1,…,MM}

                N1:{M1,…,MM}

                …

                NK:{M1,..,MM}

行为有：结交 T( Mi.Parteners.Add(Nj) and Nj.Parterners.Add(Mi) )

                     绝交 T( Mi.Parteners.Remove(Nj) and Nj.Parents.Remove(Mi) )

           角色：伙伴(r)

           限制

 [

      一）C 可以是A的伙伴的同时也可以是B的伙伴。《多样性》

      二）C是A的伙伴==A是C的伙伴。《等价性》

      三）但是B可以是A的伙伴也可以不是A的伙伴《不可传递性》

 ]。

 ----------------------说明--------------------------

一）R1，1:1; R2,1:N; R3,M:N; eA:实体A; eB:实体B

二）数据实体之间的关系可以统一表示为

eA -----------{R1 or R2 or R3}-------------eB

三）R1 ，R2，R3是相互排斥的，只能选择其中的一种且必须选择一种。

---------------------------------------------------------------

3:相应的持久化存储文件的存储结构。

一)R1 关系.

   storageA ---------{a.PK,b.PK}[a.PK唯一，b.PK唯一]-----------storageB

二)R2 关系

   storageA ----------{a.PK,b.PK}[a.PK唯一]---------------------storageB

三)R3 关系

   storageA-----------{a.PK,b.PK}-------------------------------storageB

======a.PK是storageA的唯一性标识符。b.PK是storageB的唯一性标识符=======

4:相应的持久化存储文件的表现形式。(以关系数据库为存储介质时）

用例：

 

 TabGirl(GirlId ,Name,Age,Phone) 

<-----Wife(GirlId,BoyId) ---->

 TabBoy(BoyId ,Name,Age,Phone)

 <其它类似的关系有：国家与宪法的关系>

 

 TabParent(ManId ,Name,Address,YearIncome,IdentityCardNum)

      <----ParentSons(ManId,ChildrenId)--->

 ChildRen(ChildrenId,birthDate)

<基它类似的关系有:奴隶与奴隶主的关系>

 

TabUser(UserId,UserName,RegisterTime)

     <---userRoles(UserId,RoleId)------->

TabRole(RoleId,RoleName,CreatTime,ApplicationName)

<其它类似的关系还有:订单与商品的关系>

 

多表之间的关系我认为可以采用视图之类的东西来形成这样的三种基本关系.

5:从本质上来讲，关系数据库中只存在两种东西。

   一个是由不可分的原子属性组成的行集。

   另一个不同行集之间的关系。

一）面向对象的基本原则。

１）抽象决定细节，细节依赖抽象。

 

２）模块是可扩展的，但是不可以改动。

３）接口隔离。

二）优先考虑系统的行为。

1)数据库是实现细节！应该尽可能的推迟考虑数据库。有太多的应用程序之所以和数据库绑定在一起而无法分离，就是因为一开始设计时就把数据库考虑在内。

2)抽象的定义：本质部分的放大，无关紧要的部分去除。在项目的当前阶段数据库是无关紧要的；它只不过是一项用来存储和访问数据的技术细节而已。