论数据仓库架构前需要考虑的问题
11 views
Skip to first unread message
Solo Zhu
May 19, 2008, 11:32:57 PM5/19/08
to ttnn BI 观点, tt...@googlegroups.com
论数据仓库架构前需要考虑的问题
除掉满足需求以外，一个好的数据仓库需要考虑的是使用（应用）是否方便，维护是否方便，扩展是否方便，开发是否方便。
使用:
好的系统首先解决的是使用问题，如果最好的操作人员不满意的话，通常应用效果都会比较差的，所以很多公司很注重用户场景的设计，我曾经和微软的
同事有过一段时间的接触，发现他们很注重一般企业不注重的问题，比如我们在查询时，选择条件，有的是大于，有的是小于，有的是大于等于等等，通常这样的
情况，在事先没有统一的要求和规定，但是他们对于每一个用户场景的描述都很清晰，首先按照业务上的应用，其次按照固定的用户习惯.这就是为什么微软的东
西总是被称为傻瓜式的，其实我个人觉得MS的场景真的可以当作傻瓜式来操作，基本上按照他们给的help就可以学会基本的东西了。说回来，我们BIDW
需要这样的吗？回答是肯定的，我们有固定报表，有分析型报表，有图表，ad-hoc，还有KPI等dashboard等等，那么我们有研究过或者指定一
些规定来描述吗？什么样的情况需要用固定报表，什么样的需要分析性的，什么样的用线性图，什么样的用柱状图，图和表的排列应该是怎么样的，报表的名字应
该怎么取，格式和大小是怎么样，等等等，我想我们BIDW的很多同仁都没有好好的去思考这样的问题，其实如果我们有这样的前台展现的规定，而且执行下
去，将来企业就算不断的换维护人员，升级系统，都可以比较方便。
维护：
说到维护，我想很多甲方的同仁都深有感触，维护，我们平时都维护什么了？报表的修改，报表的增加，临时统计老板需要的数据，ETL，系统升级，
数据库的清理，历史数据的转接与转存。这就带来我们需要去维护数据库，增加新的表，有的时候我们不清楚原系统的业务逻辑，还要另外来一套表或者报表，一
个个的维护人员的更迭，倒是同类型的表很多，同类型的数据很多，比如原来的表叫做T_Sales，现在不清楚逻辑，就吧就够稍微改一下，变成
T_Sales_new或者其他的名字，这样的数据库，数据仓库的模型非常非常的多，到了后来大家都是过一天是一天，只要不出问题，到了最后没有办法，
又得重新来。如果尽量的避免这样的问题了，我的经验是可以从几个方面去考虑：
1：文档。现在就算比较清晰的文档一般也是在系统开始建设的时候描述的比较清晰，但是一旦开始维护系统了，文档慢慢的也就失去维护的价值了，到了
最后，也许和系统的关系就不是很大了，但是我们还是要清楚的描述它，因为就算系统的更迭，以后的维护者还是可以按照最初的文档看出一些道道来，我最近就
遇到这样的问题了。感觉文档还是非常的宝贵。一定要清楚的描述原系统的业务范围，源表，ETL还有ODS，DW，report等几者的关系，最好这样的
数据能放到数据库里面，而且专门为这些元数据做一些报表，设置一些检查的rule，这样我们就可通过查看report来检查我们是否在更新系统后是否更
新了文档，是否更新了元数据。
2：数据字典。我们经常在数据仓库中遇到A B C D这样的字母表示的业务意义，这些东西其实业务人员大多都很清楚的，但是IT的就不一定了，
这给我们和业务人员之间的沟通造成了一些不方便，其实这样的类型 代号，一般的企业也只有不到50个类型，通常使用的也只有10-20种，我们可以在建
模或者在分析数据的时候，取得这些数据，然后建立一张数据字典，我们的更改删除等操作都可以用数据的状态字段来表示。而且还有很多将来可以直接转化为维
表。
3：培训材料。业务人员和IT的维护人员，都有换人的时候，他们不懂的可能经常会问，而我们也会经常去给他们讲解。如果我们还怕麻烦的话，我们可
以制作一下简单的，简易的操作手册或者比较容易理解的视频文件，提供给他们，最好我们把前期维护的内容都记下来，把问题分类，简单的一点的，比如系统字
符的一些设置等等的，都可以写下来，放到网上去，做一个Q&A,这样可以减少很多的工作量。
扩展：
扩展这个范畴就比较抽象了，我们具体一点的来说，为什么要扩展，就是系统满足不了新的业务要求，业务在变化，管理在变化，我们如何去考虑改变系
统去适应这些变化。主要有下面几个方面：
模型：我们无论是关系模型还是多维模型或者混合的模型，我们都需要考虑将来，如果原系统发生变化了，或者说原系统的表结构发生变化了，系统是否
很方便的去修改和维护。比如我们的财务系统，会计法或者税法，或者相关的法律发生变化，我们的财务报表就有可能发生变化，那边对于的财务模型是否需要发
生变化了，如果要变化，是否可以轻易的修改了。其实我们说到这里，都觉得应该的，但是现在的问题是我们怎么去考虑模型的建设。如果我们在建模的时候有
domain（ERWin和powerdesigner都有这个概念）的话，那就最好，我们可以很方便的修改类型。可以方便的修改结构，而且还可以查看
系统的一些相关的变化。如果没有domain了，特别是大型的企业，而且业务复杂，一般没有自己的企业数据元，如果数据仓库是纯多维模型的话，我建议我
们的ODS采用关系模型去搭建，这样发生变化的时候，我们也不会对DW有太大的影响。
ETL：我个人比较喜欢采用ELT的方式，将数据转换放到SP中，因为可以用一个总的SP去适应所以的ETL，然后在设置一些和功能对应的子
SP，这样既可以采用事务去管理，也好通过ETL package的编号去维护。对于一般的insert，delete和update的修改都表容易，
特别是异构数据库的之间的数据传递。当时于特殊的ETL，我们可以特殊考虑。
BI，这里的BI其实就是指的是我们最终用户操作的界面，一般都是web的，有report，adhoc，dashboard等等，这里通常都
是一些需求的变化。如何的扩展更多的还是要取决于我们的使用平台。最好在设计之前考虑webservice这个功能，因为这个功能是跨平台的，我们可以
从不同的系统交互数据。
开发：
最后我们谈谈开发，其实BIDW的开发的难度以此为ETL，data model，report展现。ETL的工作量基本上要占40-60%，
而它又在data model之后，所以我们需要考虑的还是在data model怎么样为ETL提供方便，首先我们可以在见表的时候用schema来
区分表，用固定的name convertion来标示字段，比如code 用CD，name用NM等等，如果ODS和DW有多层的话，建议用同样的
表，同样的名称。这样很多ETL工具在mapping的时候，就可以自动的匹配出来。
对于ETL的开发，我建议在ETL前，先分析ETL流程，然后开发1-2个通用的package，以后就已这连个为模板，不断的copy和修
改，这样可以节省很大的工作量。如果能采用package和subpackage的话，那就更好，可以团队写作去开发了。
本帖将来本人的blog上同步：http://bidwhome.itpub.net/
除掉满足需求以外，一个好的数据仓库需要考虑的是使用（应用）是否方便，维护是否方便，扩展是否方便，开发是否方便。
使用:
好的系统首先解决的是使用问题，如果最好的操作人员不满意的话，通常应用效果都会比较差的，所以很多公司很注重用户场景的设计，我曾经和微软的
同事有过一段时间的接触，发现他们很注重一般企业不注重的问题，比如我们在查询时，选择条件，有的是大于，有的是小于，有的是大于等于等等，通常这样的
情况，在事先没有统一的要求和规定，但是他们对于每一个用户场景的描述都很清晰，首先按照业务上的应用，其次按照固定的用户习惯.这就是为什么微软的东
西总是被称为傻瓜式的，其实我个人觉得MS的场景真的可以当作傻瓜式来操作，基本上按照他们给的help就可以学会基本的东西了。说回来，我们BIDW
需要这样的吗？回答是肯定的，我们有固定报表，有分析型报表，有图表，ad-hoc，还有KPI等dashboard等等，那么我们有研究过或者指定一
些规定来描述吗？什么样的情况需要用固定报表，什么样的需要分析性的，什么样的用线性图，什么样的用柱状图，图和表的排列应该是怎么样的，报表的名字应
该怎么取，格式和大小是怎么样，等等等，我想我们BIDW的很多同仁都没有好好的去思考这样的问题，其实如果我们有这样的前台展现的规定，而且执行下
去，将来企业就算不断的换维护人员，升级系统，都可以比较方便。
维护：
说到维护，我想很多甲方的同仁都深有感触，维护，我们平时都维护什么了？报表的修改，报表的增加，临时统计老板需要的数据，ETL，系统升级，
数据库的清理，历史数据的转接与转存。这就带来我们需要去维护数据库，增加新的表，有的时候我们不清楚原系统的业务逻辑，还要另外来一套表或者报表，一
个个的维护人员的更迭，倒是同类型的表很多，同类型的数据很多，比如原来的表叫做T_Sales，现在不清楚逻辑，就吧就够稍微改一下，变成
T_Sales_new或者其他的名字，这样的数据库，数据仓库的模型非常非常的多，到了后来大家都是过一天是一天，只要不出问题，到了最后没有办法，
又得重新来。如果尽量的避免这样的问题了，我的经验是可以从几个方面去考虑：
1：文档。现在就算比较清晰的文档一般也是在系统开始建设的时候描述的比较清晰，但是一旦开始维护系统了，文档慢慢的也就失去维护的价值了，到了
最后，也许和系统的关系就不是很大了，但是我们还是要清楚的描述它，因为就算系统的更迭，以后的维护者还是可以按照最初的文档看出一些道道来，我最近就
遇到这样的问题了。感觉文档还是非常的宝贵。一定要清楚的描述原系统的业务范围，源表，ETL还有ODS，DW，report等几者的关系，最好这样的
数据能放到数据库里面，而且专门为这些元数据做一些报表，设置一些检查的rule，这样我们就可通过查看report来检查我们是否在更新系统后是否更
新了文档，是否更新了元数据。
2：数据字典。我们经常在数据仓库中遇到A B C D这样的字母表示的业务意义，这些东西其实业务人员大多都很清楚的，但是IT的就不一定了，
这给我们和业务人员之间的沟通造成了一些不方便，其实这样的类型 代号，一般的企业也只有不到50个类型，通常使用的也只有10-20种，我们可以在建
模或者在分析数据的时候，取得这些数据，然后建立一张数据字典，我们的更改删除等操作都可以用数据的状态字段来表示。而且还有很多将来可以直接转化为维
表。
3：培训材料。业务人员和IT的维护人员，都有换人的时候，他们不懂的可能经常会问，而我们也会经常去给他们讲解。如果我们还怕麻烦的话，我们可
以制作一下简单的，简易的操作手册或者比较容易理解的视频文件，提供给他们，最好我们把前期维护的内容都记下来，把问题分类，简单的一点的，比如系统字
符的一些设置等等的，都可以写下来，放到网上去，做一个Q&A,这样可以减少很多的工作量。
扩展：
扩展这个范畴就比较抽象了，我们具体一点的来说，为什么要扩展，就是系统满足不了新的业务要求，业务在变化，管理在变化，我们如何去考虑改变系
统去适应这些变化。主要有下面几个方面：
模型：我们无论是关系模型还是多维模型或者混合的模型，我们都需要考虑将来，如果原系统发生变化了，或者说原系统的表结构发生变化了，系统是否
很方便的去修改和维护。比如我们的财务系统，会计法或者税法，或者相关的法律发生变化，我们的财务报表就有可能发生变化，那边对于的财务模型是否需要发
生变化了，如果要变化，是否可以轻易的修改了。其实我们说到这里，都觉得应该的，但是现在的问题是我们怎么去考虑模型的建设。如果我们在建模的时候有
domain（ERWin和powerdesigner都有这个概念）的话，那就最好，我们可以很方便的修改类型。可以方便的修改结构，而且还可以查看
系统的一些相关的变化。如果没有domain了，特别是大型的企业，而且业务复杂，一般没有自己的企业数据元，如果数据仓库是纯多维模型的话，我建议我
们的ODS采用关系模型去搭建，这样发生变化的时候，我们也不会对DW有太大的影响。
ETL：我个人比较喜欢采用ELT的方式，将数据转换放到SP中，因为可以用一个总的SP去适应所以的ETL，然后在设置一些和功能对应的子
SP，这样既可以采用事务去管理，也好通过ETL package的编号去维护。对于一般的insert，delete和update的修改都表容易，
特别是异构数据库的之间的数据传递。当时于特殊的ETL，我们可以特殊考虑。
BI，这里的BI其实就是指的是我们最终用户操作的界面，一般都是web的，有report，adhoc，dashboard等等，这里通常都
是一些需求的变化。如何的扩展更多的还是要取决于我们的使用平台。最好在设计之前考虑webservice这个功能，因为这个功能是跨平台的，我们可以
从不同的系统交互数据。
开发：
最后我们谈谈开发，其实BIDW的开发的难度以此为ETL，data model，report展现。ETL的工作量基本上要占40-60%，
而它又在data model之后，所以我们需要考虑的还是在data model怎么样为ETL提供方便，首先我们可以在见表的时候用schema来
区分表，用固定的name convertion来标示字段，比如code 用CD，name用NM等等，如果ODS和DW有多层的话，建议用同样的
表，同样的名称。这样很多ETL工具在mapping的时候，就可以自动的匹配出来。
对于ETL的开发，我建议在ETL前，先分析ETL流程，然后开发1-2个通用的package，以后就已这连个为模板，不断的copy和修
改，这样可以节省很大的工作量。如果能采用package和subpackage的话，那就更好，可以团队写作去开发了。
本帖将来本人的blog上同步：http://bidwhome.itpub.net/
Solo Zhu
May 19, 2008, 11:32:57 PM5/19/08
to ttnn BI 观点, tt...@googlegroups.com
Qing
May 19, 2008, 11:47:52 PM5/19/08
to tt...@googlegroups.com
interstage
May 19, 2008, 11:53:14 PM5/19/08
to ttnn BI 观点
赞同你的描述,作为IT实施商去实施DW的话,的确应该这样去考虑这些问题:
1,先把"使用"作为第一个重要点,是很不容易的,因为人机交互是目前IT实施公司很少考虑的.
2,再把"维护"作为第2点,说明要求了项目在IT层面的可持续性
3,扩展,尽管这里的"扩展"是IT实施的可扩展性,但已经很不错了,只是如何利用优秀的模型,利用ETL规则定义,和交互界面来支撑扩展,都能够考虑
到.
4,把开发放在最后,这也是很正确的,其中,我个人认为就工作量而言,ETL至少占70%,就工作复杂度而言data model和report各占一
半,一个优秀的data model基本上能出很多张报表,但有时候做一张report需要化几天时间,无法用data model来归纳,只能通过存
储过程,外部计算,报表本身计算来实现.
看来你的确是很有经验的DW实施者,期待你经常把你的IT经验和我们共享. 这个经验是真正IT实现的经验,不是"忽悠"出来
但个人认为,就是全部实现这个,企业的IT部门会满意你们的工作,但企业的运营部门不一定能从这个DW中得到项目真正的期望目标. 但这个目前不是IT
实施公司的错.
1,先把"使用"作为第一个重要点,是很不容易的,因为人机交互是目前IT实施公司很少考虑的.
2,再把"维护"作为第2点,说明要求了项目在IT层面的可持续性
3,扩展,尽管这里的"扩展"是IT实施的可扩展性,但已经很不错了,只是如何利用优秀的模型,利用ETL规则定义,和交互界面来支撑扩展,都能够考虑
到.
4,把开发放在最后,这也是很正确的,其中,我个人认为就工作量而言,ETL至少占70%,就工作复杂度而言data model和report各占一
半,一个优秀的data model基本上能出很多张报表,但有时候做一张report需要化几天时间,无法用data model来归纳,只能通过存
储过程,外部计算,报表本身计算来实现.
看来你的确是很有经验的DW实施者,期待你经常把你的IT经验和我们共享. 这个经验是真正IT实现的经验,不是"忽悠"出来
但个人认为,就是全部实现这个,企业的IT部门会满意你们的工作,但企业的运营部门不一定能从这个DW中得到项目真正的期望目标. 但这个目前不是IT
实施公司的错.
Qing
May 20, 2008, 12:15:51 AM5/20/08
to tt...@googlegroups.com
interstage真是难得赞同一下，而且还有理有据。
对于"使用"这点来说，我认为更应该多考虑如何接受使用者的反馈，在很多时候，这都是被忽略的。系统的开发者急着将一个功能推送给使用者，却不关心他们的操作。这种做法跟企业停留在事务系统，而缺乏对数据进行分析来改善自己的做法差不多，可以说是BI人的悲哀。
我想一个好的架构应该是能够不断暴露使用者需求的，而突破传统的需求收集方法，口对口的需求访谈"你有什么需求？"。
2008/5/20 interstage <buer...@gmail.com>:
赞同你的描述,作为IT实施商去实施DW的话,的确应该这样去考虑这些问题:
1,先把"使用"作为第一个重要点,是很不容易的,因为人机交互是目前IT实施公司很少考虑的.
...
Solo Zhu
May 20, 2008, 9:53:02 AM5/20/08
to ttnn BI 观点
其实我觉得好的系统，首先考虑的就是使用者的习惯和使用方法，否则系统很难有生命力。我们做一个系统，不需要多深的技术，不需要如何去构架的很完美，如
果系统很好，首先被记住和称赞的就是使用者。原来我和电力部门打过几年的交到，那个时候java和c++非常的流行，但是一个家伙用VB
+foxbase做了一个很简单系统，居然没有人不说这个系统不好用，等到我们的系统上线了，用户包括管理者就拿着这个系统对我们说，你们可以参考这样
的系统去做，等我们看到了这个系统，发现其实差别不是很大，只是用户输入一些数字之后可以自动的跳到下一个输入窗口，输入一个帐号的前几个字符，它可以
自动的匹配，让你去选择，从而不用继续输入下去了，还有很多很多的比较人性化的操作。
其实用户需要的就是这样的系统。
果系统很好，首先被记住和称赞的就是使用者。原来我和电力部门打过几年的交到，那个时候java和c++非常的流行，但是一个家伙用VB
+foxbase做了一个很简单系统，居然没有人不说这个系统不好用，等到我们的系统上线了，用户包括管理者就拿着这个系统对我们说，你们可以参考这样
的系统去做，等我们看到了这个系统，发现其实差别不是很大，只是用户输入一些数字之后可以自动的跳到下一个输入窗口，输入一个帐号的前几个字符，它可以
自动的匹配，让你去选择，从而不用继续输入下去了，还有很多很多的比较人性化的操作。
其实用户需要的就是这样的系统。
tosimple
May 20, 2008, 11:23:06 AM5/20/08
to ttnn BI 观点
对于使用者的习惯，其实可以从使用者的点击流来分析。 用户使用留下了大量的操作日志，我们往往只是拿来分析错误原因，而忽略了对用户使用习惯的分
析。
同时，通过分析用户的使用习惯来改进dwbi建设，不由让我想起了interstage 的持续改进。这不就是一个持续改进的过程么。
析。
同时，通过分析用户的使用习惯来改进dwbi建设，不由让我想起了interstage 的持续改进。这不就是一个持续改进的过程么。
Solo Zhu
May 20, 2008, 9:06:32 PM5/20/08
to ttnn BI 观点
我不明白如何从操作日志，点击流来分析用户的习惯
很多的习惯都是隐蔽的，需要多沟通和理解用户的使用方法。
很多的习惯都是隐蔽的，需要多沟通和理解用户的使用方法。
interstage
May 20, 2008, 9:33:55 PM5/20/08
to ttnn BI 观点
你和tosimple目标是一致的,就是在"使用"界面中更好的融合用户的习惯,这是人机交互的学科所研究.只是,你们两的采集方法不一样:
1,你希望和使用者先交流,了解操作习惯和使用方法,再归纳这些交流的情况进行界面设计.这种方法类似于现场调研方式.
2,tosimple希望让使用者先用功能实现的界面,在通过点击流来分析用户使用习惯,最后修改这个界面.
其实,我个人的经验是这样,不一定正确,仅供大家参考做BI项目的时候,是先快速开发出没有任何动态数据的界面(数据是固定的),然后让主要用户使用,
让他们提建议,再改"
On 5月21日, 上午9时06分, Solo Zhu <solof...@gmail.com> wrote:
> 我不明白如何从操作日志，点击流来分析用户的习惯
> 很多的习惯都是隐蔽的，需要多沟通和理解用户的使用方法。
1,你希望和使用者先交流,了解操作习惯和使用方法,再归纳这些交流的情况进行界面设计.这种方法类似于现场调研方式.
2,tosimple希望让使用者先用功能实现的界面,在通过点击流来分析用户使用习惯,最后修改这个界面.
其实,我个人的经验是这样,不一定正确,仅供大家参考做BI项目的时候,是先快速开发出没有任何动态数据的界面(数据是固定的),然后让主要用户使用,
让他们提建议,再改"
On 5月21日, 上午9时06分, Solo Zhu <solof...@gmail.com> wrote:
> 我不明白如何从操作日志，点击流来分析用户的习惯
> 很多的习惯都是隐蔽的，需要多沟通和理解用户的使用方法。
Steven
May 20, 2008, 9:45:23 PM5/20/08
to tt...@googlegroups.com
晕，完全是两码事
2008-05-21
Steven
发件人： interstage
发送时间： 2008-05-21 09:34:05
收件人： ttnn BI 观点
抄送：
主题： Re: 论数据仓库架构前需要考虑的问题
raullew
May 20, 2008, 11:41:40 PM5/20/08
to ttnn BI 观点
互联网有种工作叫交互设计师，就是专门做这个事情的，互联网产品的用户体验相对于别的软件是比较重要的，通常会招募平面设计专业的人才
在BI这块，我认同你的观点，拿个demo出来大家讨论讨论就行了
> > 很多的习惯都是隐蔽的，需要多沟通和理解用户的使用方法。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
在BI这块，我认同你的观点，拿个demo出来大家讨论讨论就行了
>
> - 显示引用的文字 -
interstage
May 21, 2008, 2:02:28 AM5/21/08
to ttnn BI 观点
这个＂交互设计＂领域现在也是一门学科． 按照Alan Cooper（一个牛人：VB之父，交互设计之父，微软视窗先锋奖软件梦幻奖得主，库伯交互设
计公司创始人）对＂交互设计＂的定义：＂简单的说，交互设计是人工制品、环境和系统的行为，以及传达这种行为的外形元素的设计与定义。不像传统的设计学
科主要关注形式，最近则是关注内容和内涵，而交互设计首先旨在规划和描述事物的行为方式，然后描述传达这种行为的最有效形式。＂ 而DeDream认
为：从用户角度来说，交互设计是一种如何让产品易用，有效而让人愉悦的技术，它致力于了解目标用户和他们的期望，了解用户在同产品交互时彼此的行为，了
解“人”本身的心理和行为特点，同时，还包括了解各种有效的交互方式，并对它们进行增强和扩充。交互设计还涉及到多个学科，以及和多领域多背景人员的沟
通。
按照我对新知识的学习方法（１，历史产生，２，现在情况，３未来的方向），我学习如下，供人家参考：
１．1959年，美国学者B.Shackel提出了人机界面的第一篇文献《关于计算机控制台设计的人机工程学》
２．1960年，Liklider JCK首次提出“人机紧密共栖的概念，被视为人机界面学的启蒙观点
３．1969年，召开了第一次人机系统国际大会，同年第一份专业杂志"国际人机研究（IJMMS）"创刊。
这样＂交互设计＂理论的初创期结束，进入奠基期：
４．从1970年到1973年出版了四本与计算机相关的人机工程学专著
５．1970年成立了两个HCI研究中心：一个是英国的Loughbocough大学的HUSAT研究中心，另一个是美国Xerox公司的Palo
Alto研究中心
奠基期结束后，进入发展期（1980-1995）：使＂交互设计＂在理论方面从人机工程学独立出来，更加强调认知心理学以及行为学和社会学等学科的理论
指导
，而在实践范畴方面，从人机界面拓延开来，强调计算机对于人的反馈交互作用。"人机界面"一词被"人机交互"所取代。HCI中的"I"，也
由"Interface(界面/接口)"变成了"Interaction(交互)"。
自1996年后,＂交互设计＂的研究重点放在了智能化交互，多模态（多通道）-多媒体交互，虚拟交互以及人机协同交互等方面，也就是放在"以人为在中
心"的人机交互技术方面。
所以,我感觉＂交互设计＂是一门美学,BI项目中需要这门美学的支撑,就象一个建筑项目中,分建筑设计师,结构设计师,建筑建造师,建筑监理师等,建筑
设计师就是建筑美学的大师,是所有人中工资最高的,结构设计师是BIDW项目的架构设计师. 当然BI项目中,目前还不可能达到交互设计师的工资比架构
设计师高,不然某些所谓的"架构设计师"又要歇斯底里了,又要从神坛中下来了,并大叫"凭什么我的工资不如搞BI界面的高",呵呵.
> > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
计公司创始人）对＂交互设计＂的定义：＂简单的说，交互设计是人工制品、环境和系统的行为，以及传达这种行为的外形元素的设计与定义。不像传统的设计学
科主要关注形式，最近则是关注内容和内涵，而交互设计首先旨在规划和描述事物的行为方式，然后描述传达这种行为的最有效形式。＂ 而DeDream认
为：从用户角度来说，交互设计是一种如何让产品易用，有效而让人愉悦的技术，它致力于了解目标用户和他们的期望，了解用户在同产品交互时彼此的行为，了
解“人”本身的心理和行为特点，同时，还包括了解各种有效的交互方式，并对它们进行增强和扩充。交互设计还涉及到多个学科，以及和多领域多背景人员的沟
通。
按照我对新知识的学习方法（１，历史产生，２，现在情况，３未来的方向），我学习如下，供人家参考：
１．1959年，美国学者B.Shackel提出了人机界面的第一篇文献《关于计算机控制台设计的人机工程学》
２．1960年，Liklider JCK首次提出“人机紧密共栖的概念，被视为人机界面学的启蒙观点
３．1969年，召开了第一次人机系统国际大会，同年第一份专业杂志"国际人机研究（IJMMS）"创刊。
这样＂交互设计＂理论的初创期结束，进入奠基期：
４．从1970年到1973年出版了四本与计算机相关的人机工程学专著
５．1970年成立了两个HCI研究中心：一个是英国的Loughbocough大学的HUSAT研究中心，另一个是美国Xerox公司的Palo
Alto研究中心
奠基期结束后，进入发展期（1980-1995）：使＂交互设计＂在理论方面从人机工程学独立出来，更加强调认知心理学以及行为学和社会学等学科的理论
指导
，而在实践范畴方面，从人机界面拓延开来，强调计算机对于人的反馈交互作用。"人机界面"一词被"人机交互"所取代。HCI中的"I"，也
由"Interface(界面/接口)"变成了"Interaction(交互)"。
自1996年后,＂交互设计＂的研究重点放在了智能化交互，多模态（多通道）-多媒体交互，虚拟交互以及人机协同交互等方面，也就是放在"以人为在中
心"的人机交互技术方面。
所以,我感觉＂交互设计＂是一门美学,BI项目中需要这门美学的支撑,就象一个建筑项目中,分建筑设计师,结构设计师,建筑建造师,建筑监理师等,建筑
设计师就是建筑美学的大师,是所有人中工资最高的,结构设计师是BIDW项目的架构设计师. 当然BI项目中,目前还不可能达到交互设计师的工资比架构
设计师高,不然某些所谓的"架构设计师"又要歇斯底里了,又要从神坛中下来了,并大叫"凭什么我的工资不如搞BI界面的高",呵呵.
>
> - 显示引用的文字 -
Reply all
Reply to author
Forward
0 new messages