graph-relational model 怎么翻译最合适? - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
fantix
V2EX    数据库

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

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

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

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

    背景:楼主要翻译一篇尚未发布的解释 graph-relationalmodel 的文章,不想保留太长的英文名字( 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     Solana     1021 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 26ms UTC 18:47 PVG 02:47 LAX 10:47 JFK 13:47
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86