V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
fantix
V2EX  ›  数据库

graph-relational model 怎么翻译最合适?

  •  
  •   fantix · 2022-02-23 00:22:11 +08:00 · 898 次点击
    这是一个创建于 795 天前的主题,其中的信息可能已经有所发展或是发生改变。

    先放我的候选项,个人倾向于“关系弧”,谐音关系户……

    • 图-关系模型 / 图-关系型数据库
    • 图关系模型 / 图关系型数据库
    • 关系图模型 / 关系图数据库
    • 关系弧模型 / 关系弧数据库

    背景:楼主要翻译一篇尚未发布的解释 graph-relational model 的文章,不想保留太长的英文名字( graph-relational 模型),毕竟关系模型 /关系数据库是大家已经接受了的翻译。另外,图-关系模型还好,但是图-关系数据库就容易产生歧义,中文语感也不好,其他几个带“图”的选项也是如此,因而有此一问。

    因为都是数学和 CS 术语,为了便于讨论,我先尝试通俗地解释一下关系模型。我现在知道 V 站大佬多了,所以这一段请大佬华丽跳过,但如有纰漏还望指出。简单来说,关系模型是对数据的一种抽象和变形方法。数据的最小单位是一个值,可以是一个整数,也可以是一段文字,等等。在一堆特定的数据中,总会有一些值有着同样的取值范围,比如 2020 年地球人年龄的取值范围就是 0-200 ,2007 届某大学学生姓名的取值范围就是当年所有的学生名字。那么“毕业时 20 岁的张三”就是一个所谓“tuple”元组:(张三,20 ),而“关系”就是指某些元组符合相同元组模式的规律——其实就是一张报表:学生毕业年龄表。关系模型简单来说就是用表结构来对数据进行建模,然后可以用数学上的一些方法对这些“关系”进行操作,得到不同的想要的结果,比如结合其他表,算出找工作所需的平均时间等等。以此为基础开发的数据库就叫关系型数据库,你常用的 SELECT a, b FROM xxx ,或者 x LEFT JOIN y 其实都是这些数学操作,细节就不展开了。

    graph-relational 的概念不算是全新的,但出现的比较少(也许将来能火一把?)。这里的 graph-relational 模型是在关系模型的基础上,增加了三种新的概念:

    1. 每一个元组都必须有一个全局唯一的标识符,用人话讲就是,表里的每一行都必须有一个跨表不重复的 ID ;
    2. 元组中的值如果是别的元组的 ID 的话,这个值就叫做一个“弧”( link ),表示关联关系,弧也可以有自己的属性;
    3. 元组中的每一个值都升级为一个集合,集合里的每一个值的取值范围都必须是一样的。集合有个概念叫“基数”( cardinality ),后面详细说。

    第一条不用多说,就是加了个内置的 ID 字段。第二条中“弧”是图论里的一个概念,就是有向图的边。因为这个 graph-relational 模型强化了关系模型元组之间的“链接”,有了“图”的特性,所以才叫 graph-relational 模型。第三条“基数”其实很简单,用来限制集合里值的个数,一共有五种基数:(集合)必须为空、最多一个值、有且仅有一个值、最少一个值、没有任何限制。用我即将翻译的文章中的一个例子来讲最简单:

    type Person {
        required property name -> str;
    }
    
    type Movie {
        property description -> str;
        required property title -> str;
        multi property alt_titles -> str;
        required multi link actors -> User {
            property character_name -> str;
        };
    }
    

    这里有两个关系:Person 和 Movie ,其中 Person 有一个属性 name,Movie 有四个属性:

    • description 不是必选属性,所以 [最多一个值] ,可以为空;
    • title 是必选属性,所以是 [有且仅有一个值] ,对应 SQL 中的 NOT NULL 约束;
    • alt_titles 可以有多个值,也可以为空,所以 [没有任何限制] ;
    • actors 是必选属性,但可以有多个值,因此 [最少一个值] 。另外,actors 还是一个弧,由 Movie 指向 Person ,并且带有自己的属性 character_name,表示演员这个人在这部电影中饰演的角色。

    再写我就要把文章都翻译完了。回到问题,如果我把 graph-relational model 翻译成“关系弧模型”,graph-relational database 就是“关系弧数据库”,大家意下如何?我自己觉得很有既视感,既保留了其关系模型的基础(符合事实),又有意误用了“关系”在汉语中不同于“relation”的二义性(同时表示 relationship ),“关系弧”听上去就像是数据之间的错综复杂的关联弧线,严格定义又可以解释为关系代数中的“关系”加上图论中的“弧”,依次对应 relational 和 graph 。另外,没有把“link”翻译成“链接”,而是直接叫“弧”,一方面为了对应“关系弧模型”,另一方面我感觉“链接”“连接”“联结”太容易搞混了,而且有点像“超链接”,总之不喜欢“链接”的叫法。再者,“单边弧”、“多边弧”也很准确,“多链接”或者“复链接”就怪怪的。

    欢迎不同意见和建议!这里的网友批准了,以后我就都这么叫了。

    4 条回复    2022-02-23 10:13:33 +08:00
    adoal
        1
    adoal  
       2022-02-23 00:26:39 +08:00 via iPhone   ❤️ 1
    可以探讨。但在你成为业界大佬从而你的个性被业界普遍认可之前,径直这样做,会给别人阅读带来麻烦,提高沟通成本…
    fantix
        2
    fantix  
    OP
       2022-02-23 00:30:52 +08:00
    @adoal 是的是的,就怕这个。但是又不想翻译的太生硬……有什么好的建议吗😍😍?直接用英文 graph-relational 其实也挺好……
    cmdOptionKana
        3
    cmdOptionKana  
       2022-02-23 09:22:59 +08:00   ❤️ 1
    现在翻译理念已经变了,一般尽量按照最常见的字面意思去直译最好,方便不同水平的人轻松地与英语对应起来,也方便翻译软件自动翻译。

    尤其是技术文档,怎么省力怎么来,没有歧义就行,技术翻译的核心还是快速把技术用起来,不需要追求文采。

    如果是文学翻译倒是可以花时间精力去追求信达雅,但技术文档花这个时间精力总觉得有点本末倒置了。
    fantix
        4
    fantix  
    OP
       2022-02-23 10:13:33 +08:00 via iPhone
    @cmdOptionKana 很有道理!其实英文的 graph-relational 本身就没那么精准,那么叫图-关系模型应该也方便对照。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1326 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 17:37 · PVG 01:37 · LAX 10:37 · JFK 13:37
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.