I
import
Unregistered / Unconfirmed
GUEST, unregistred user!
第三十八章 面向对象数据库基础
第二节 数据对象的标识
我们在关系数据库的设计和开发中，可能经常需要一些唯一的编号或标识，用来作为关键字，以区别每一个不同的人，每一张不同的单据，每一次不同的信息登记，等等。并且，我们也一直采用这些编号和标识，作为关系的连接字段。但是，要保证编号或标识是完全唯一的，却是一个不大不小的难题。 下面我们将详细讨论这一问题，并希望能从另一个高度来理解这一问题。不过，我们首先来看看问题是怎样由来的。现在，给大家讲一个故事。 从前，在北京降生了一个漂亮的小女孩。接生的李阿姨说，她的声音这么大，好象想要全世界的人都听到。 他的父母就为她取了一个很好听的名字，叫“王菲”。于是，所有的小朋友就叫她“王菲”，“王菲”就是她童年的标识。 在她上初二的时候，认识了二班另一个叫“王菲”的同学，而且和她同一天生日。不过，同学们常常将她俩叫错，后来，就分别叫她们“大王菲”和“小王菲”。 在大王菲18岁的那一年，她领到了她的身份证。从此，她有了新的身份标识“100321690808022”，这一标识可以唯一区别中国大陆的每一个人。同时，原来二班的“小王菲”也领到了她自己的身份证，“100321690808006”。于是，人们就可以用身份证号，唯一标识两个“王菲”了，虽然谁也不会直接叫她们的身份证号码。 由于她的歌唱的非常好，没多就就成了歌星。歌迷们将“王菲”这一标识与她的歌紧紧地联系在一起。 后来她去了香港发展，并将自己的名称更改为“王靖雯”，同时还领到了香港的身份证，有了香港的身份标识。 没多久，王靖雯和一个弹电吉他的小子相爱了。那小子说，还是“王菲”这个名字好听。后来，“王靖雯”又变回“王菲”了。结果，歌迷们又遇到了麻烦，是将她的歌关联到“王菲”还是“王靖雯”呢，在歌迷中引起一阵混乱。 她和那个弹电吉他的小子结婚了，香港政府将他们的身份证号码，用结婚证书关联起来。可是，月老在酒醒之后发现了这一错误，就将关联的记录删除了。 虽然，她和那个弹电吉他的小子分手了，但是，正如接生的李阿姨说的那样，她的声音的确让全世界的人都听到了。 讲完这个故事之后，你应该能领悟到设计数据库的一些哲理。 不管王菲的外部属性和内部属性怎样变化，但王菲还是王菲，不是二班的那个“王菲”。也就是说，王菲的灵魂未变，她是不会改变的，就象哲学上所说的“不以人的意志为转移”。这种唯一表示对象本身的东西，就是对象标识！ 对象标识是唯一的。也就是说，即使两个对象，他们的外部属性完全一样，但它们的对象标识是不同的。毕竟，同名同姓甚至同一天出生的大王菲和小王菲是两个不同的人。 对象的标识是永恒不变的。一旦对象产生，它的标识就自然地、唯一地产生了。尽管王菲换了名，身份证号也变过，但王菲的对象标识未变。即使到了下个世纪，她的对象标识也将依然存在于歌迷们的们的心中。 对象的标识是描述关系的基础。王菲唱的歌是王菲唱的，不是初二二班的那个“王菲”唱的。王靖雯唱的歌就是王菲唱的歌，有的歌迷只将歌曲和歌手的人名关联起来，难怪会出混乱。香港政府也犯相同的错误，将王菲的身份证号码这一内部属性，跟那个弹电吉他的小子关联起来，也许就是命运的错误。 在关系数据库中，表的每一元组（记录）描述了对象的各个属性。也需要人为地选择某些对象属性字段作为关键字，以标识不同的数据对象。 关系数据库的理论说，一个表中，所有列的值都相同的行，也就是字段都相同的两条记录，描述的是同一数据对象。为了区分属性相同，但对象不同的大王菲和小王菲，就需要引入关键字的概念。于是，大王菲和小王菲都才有了身份证号码。 关系数据库的理论，强行将对象的属性定义为关键字，以区别不同的对象，这才给我们留下了“插入异常”、“修改异常”和“删除异常”，等等，让我们头痛多年的问题。正是因为这一原因，初二的同学才会混淆“王菲”和二班的“王菲”，歌迷们才会搞不清“王靖雯”和“王菲”的关系，这些错误在现实中也是存在的。 其实，对象的标识应该是和对象属性不同的东西，对象的标识才是数据对象的唯一关键字，不以人的意志为转移的。象人的姓名和身份证号是否应该唯一，以及单据编号是否连续等等，是由人们的规则确定的，与人们的意识有关。 那么，到底应该用什么东西来作对象标识呢？ 如果，你的数据库只是临时管理初二二班的作业本，用学生姓名作对象标识又未尚不可。如果，你的数据库管理的是中国大陆的户口档案，肯定可以用身份证号码作对象标识，不过，身份证号升位之后，你又要辛苦了。 如果，你的数据库要管理整个宇宙的信息，那么，就只能自己产生标识了！ 为数据产生唯一的对象标识，一直都没有一个公认的好方法。不过，我们可以作一些有益的探讨。目前，大致有两种方法用于产生对象标识： 一． 增量产生 这种方法就是每次产生对象标识时，到数据库里查找一下最大的对象标识。新的对象标识将在当前最大对象标识基础上增量生成，然后，新的对象标识又成为数据库中的最大对象标识。 这中方法可以保证在一个数据库内可以为每一对象生成唯一标识，并且保存对象标识所用的字节数很少（例如，一个整数）。这种对象标识，在数据库内查询和索引都有较高的效率。 但是，由于这种方法在每次产生对象标识时，需要访问数据库。特别是在多用户使用时，还要采用数据库的事务机制来防止不同用户产生相同标识。因此，产生对象标识的效率很低，特别是在批量产生时。 此外，由于这种方式生成的标识只能保证在某一数据库内是唯一的，不能直接适用于多数据库或分布式数据库环境下。在不同的数据库之间传递或同步相同的数据对象时，需要解决对象标识的转换问题。 二． 随机生成 随机生成对象标识的方法实际就是碰运气，按照某种复杂的随机算法迅速产生对象标识，碰一碰对象标识不重复的运气。只要这种算法产生的对象标识一万年才可能重复一次，那你就可以在实际开发中应用这种算法。 这种方法典型的应用就是COM对象的GUID。虽然，在理论上总有一天会产生重复的GUID标识，但我们等不到那一天，也许那是地球毁灭之后的事情。 首先，这种方法产生对象标识，不需要访问数据库，是在数据库环境之外生成对象标识。因此，标识的生成是一瞬间的事，效率非常高，即使是在批量生成的情况下。 其次，由于在多数据库或分布式数据库环境中的不同地方，也不会产生相同的对象标识，因此，在数据库之间传递或同步数据时将不存在对象标识转换的问题。LOTUS NOTES中的文档管理数据库，就大量采用这一技术。 由于，为了保证有足够的数值空间，供随机算法产生唯一标识，需要用较多的字节存放这一对象标识，将耗费较多的存储空间。GUID是一个长达128位，即16个字节的数据类型，而NOTES的文档标识也是相当长的数据类型。并且，对较大的数据类型进行索引或查找，会花费较大的时间和空间开销，不过，这一问题不向想象的那样严重。 在面向对象的数据库理论中，每一数据都抽象为一个对象，而且，每一对象都应该有一个唯一的对象标识，并且在对象诞生之后永远不便。对象的标识是唯一的关键字，对象的属性是否唯一，是商业逻辑所决定的。对象之间的关系，是通过对象标识的关联来描述的，任何对象属性的改变不会影响对象标识所连接的关系。
第二节 数据对象的标识
我们在关系数据库的设计和开发中，可能经常需要一些唯一的编号或标识，用来作为关键字，以区别每一个不同的人，每一张不同的单据，每一次不同的信息登记，等等。并且，我们也一直采用这些编号和标识，作为关系的连接字段。但是，要保证编号或标识是完全唯一的，却是一个不大不小的难题。 下面我们将详细讨论这一问题，并希望能从另一个高度来理解这一问题。不过，我们首先来看看问题是怎样由来的。现在，给大家讲一个故事。 从前，在北京降生了一个漂亮的小女孩。接生的李阿姨说，她的声音这么大，好象想要全世界的人都听到。 他的父母就为她取了一个很好听的名字，叫“王菲”。于是，所有的小朋友就叫她“王菲”，“王菲”就是她童年的标识。 在她上初二的时候，认识了二班另一个叫“王菲”的同学，而且和她同一天生日。不过，同学们常常将她俩叫错，后来，就分别叫她们“大王菲”和“小王菲”。 在大王菲18岁的那一年，她领到了她的身份证。从此，她有了新的身份标识“100321690808022”，这一标识可以唯一区别中国大陆的每一个人。同时，原来二班的“小王菲”也领到了她自己的身份证，“100321690808006”。于是，人们就可以用身份证号，唯一标识两个“王菲”了，虽然谁也不会直接叫她们的身份证号码。 由于她的歌唱的非常好，没多就就成了歌星。歌迷们将“王菲”这一标识与她的歌紧紧地联系在一起。 后来她去了香港发展，并将自己的名称更改为“王靖雯”，同时还领到了香港的身份证，有了香港的身份标识。 没多久，王靖雯和一个弹电吉他的小子相爱了。那小子说，还是“王菲”这个名字好听。后来，“王靖雯”又变回“王菲”了。结果，歌迷们又遇到了麻烦，是将她的歌关联到“王菲”还是“王靖雯”呢，在歌迷中引起一阵混乱。 她和那个弹电吉他的小子结婚了，香港政府将他们的身份证号码，用结婚证书关联起来。可是，月老在酒醒之后发现了这一错误，就将关联的记录删除了。 虽然，她和那个弹电吉他的小子分手了，但是，正如接生的李阿姨说的那样，她的声音的确让全世界的人都听到了。 讲完这个故事之后，你应该能领悟到设计数据库的一些哲理。 不管王菲的外部属性和内部属性怎样变化，但王菲还是王菲，不是二班的那个“王菲”。也就是说，王菲的灵魂未变，她是不会改变的，就象哲学上所说的“不以人的意志为转移”。这种唯一表示对象本身的东西，就是对象标识！ 对象标识是唯一的。也就是说，即使两个对象，他们的外部属性完全一样，但它们的对象标识是不同的。毕竟，同名同姓甚至同一天出生的大王菲和小王菲是两个不同的人。 对象的标识是永恒不变的。一旦对象产生，它的标识就自然地、唯一地产生了。尽管王菲换了名，身份证号也变过，但王菲的对象标识未变。即使到了下个世纪，她的对象标识也将依然存在于歌迷们的们的心中。 对象的标识是描述关系的基础。王菲唱的歌是王菲唱的，不是初二二班的那个“王菲”唱的。王靖雯唱的歌就是王菲唱的歌，有的歌迷只将歌曲和歌手的人名关联起来，难怪会出混乱。香港政府也犯相同的错误，将王菲的身份证号码这一内部属性，跟那个弹电吉他的小子关联起来，也许就是命运的错误。 在关系数据库中，表的每一元组（记录）描述了对象的各个属性。也需要人为地选择某些对象属性字段作为关键字，以标识不同的数据对象。 关系数据库的理论说，一个表中，所有列的值都相同的行，也就是字段都相同的两条记录，描述的是同一数据对象。为了区分属性相同，但对象不同的大王菲和小王菲，就需要引入关键字的概念。于是，大王菲和小王菲都才有了身份证号码。 关系数据库的理论，强行将对象的属性定义为关键字，以区别不同的对象，这才给我们留下了“插入异常”、“修改异常”和“删除异常”，等等，让我们头痛多年的问题。正是因为这一原因，初二的同学才会混淆“王菲”和二班的“王菲”，歌迷们才会搞不清“王靖雯”和“王菲”的关系，这些错误在现实中也是存在的。 其实，对象的标识应该是和对象属性不同的东西，对象的标识才是数据对象的唯一关键字，不以人的意志为转移的。象人的姓名和身份证号是否应该唯一，以及单据编号是否连续等等，是由人们的规则确定的，与人们的意识有关。 那么，到底应该用什么东西来作对象标识呢？ 如果，你的数据库只是临时管理初二二班的作业本，用学生姓名作对象标识又未尚不可。如果，你的数据库管理的是中国大陆的户口档案，肯定可以用身份证号码作对象标识，不过，身份证号升位之后，你又要辛苦了。 如果，你的数据库要管理整个宇宙的信息，那么，就只能自己产生标识了！ 为数据产生唯一的对象标识，一直都没有一个公认的好方法。不过，我们可以作一些有益的探讨。目前，大致有两种方法用于产生对象标识： 一． 增量产生 这种方法就是每次产生对象标识时，到数据库里查找一下最大的对象标识。新的对象标识将在当前最大对象标识基础上增量生成，然后，新的对象标识又成为数据库中的最大对象标识。 这中方法可以保证在一个数据库内可以为每一对象生成唯一标识，并且保存对象标识所用的字节数很少（例如，一个整数）。这种对象标识，在数据库内查询和索引都有较高的效率。 但是，由于这种方法在每次产生对象标识时，需要访问数据库。特别是在多用户使用时，还要采用数据库的事务机制来防止不同用户产生相同标识。因此，产生对象标识的效率很低，特别是在批量产生时。 此外，由于这种方式生成的标识只能保证在某一数据库内是唯一的，不能直接适用于多数据库或分布式数据库环境下。在不同的数据库之间传递或同步相同的数据对象时，需要解决对象标识的转换问题。 二． 随机生成 随机生成对象标识的方法实际就是碰运气，按照某种复杂的随机算法迅速产生对象标识，碰一碰对象标识不重复的运气。只要这种算法产生的对象标识一万年才可能重复一次，那你就可以在实际开发中应用这种算法。 这种方法典型的应用就是COM对象的GUID。虽然，在理论上总有一天会产生重复的GUID标识，但我们等不到那一天，也许那是地球毁灭之后的事情。 首先，这种方法产生对象标识，不需要访问数据库，是在数据库环境之外生成对象标识。因此，标识的生成是一瞬间的事，效率非常高，即使是在批量生成的情况下。 其次，由于在多数据库或分布式数据库环境中的不同地方，也不会产生相同的对象标识，因此，在数据库之间传递或同步数据时将不存在对象标识转换的问题。LOTUS NOTES中的文档管理数据库，就大量采用这一技术。 由于，为了保证有足够的数值空间，供随机算法产生唯一标识，需要用较多的字节存放这一对象标识，将耗费较多的存储空间。GUID是一个长达128位，即16个字节的数据类型，而NOTES的文档标识也是相当长的数据类型。并且，对较大的数据类型进行索引或查找，会花费较大的时间和空间开销，不过，这一问题不向想象的那样严重。 在面向对象的数据库理论中，每一数据都抽象为一个对象，而且，每一对象都应该有一个唯一的对象标识，并且在对象诞生之后永远不便。对象的标识是唯一的关键字，对象的属性是否唯一，是商业逻辑所决定的。对象之间的关系，是通过对象标识的关联来描述的，任何对象属性的改变不会影响对象标识所连接的关系。
