대부분의 SI 기업에 대해서 관리를 하는 방식에 대해서 품질의 기대가 이루어지는 것이 하나의 Database 에 기반한 자료의 체제에 대해서 있는 것이어서,,
결국에는 둘러보게 되는 Data List 에 대한 작업이 되는 것같습니다....
그래서 결과적으로는 기기의 일종으로는 관리적인 작업에 대해서 대부분의 SI 의 사업이 이루어진다고 뭉뚱그릴 수가 있습니다....
결과적으로 Information List 에 대해서 그것이 Knowledge 가 아니라 Data 가 되는 것이 몇몇의 Group 의 사항들이 엮이게 되면 대부분은 관리작업의 기기가,,
되는 것으로 생각이 됩니다....
그래서,,
상업적인 일에 대해서 SI 의 기기에 대해서는 그것이 대부분 최상위적인 실무의 그룹에 대해 나머지의 일에 관련해서 거의 일감을 줄 수밖에 없는 것이,,
몇몇의 Group 에 대한 사항들이 엮이는 것에 대한 조사원적인 일을 제외한다면 나머지는 <<시간소비에 대한 도구적 하청>> 으로 일이 나올 수 밖에 없습니다....
그래서,,
결과적으로 SI 라는 산업의 구조에 의해서는 대부분이 적당한 일의 껀덕지를 가지기에 원래는 SI 의 최상단의 기업과 나머지의 부분들에 대해서는,,
통계적 Group 의 사항들을 조사하는 조사원의 지부 쯤의 구조가 거의 적당하기는 합니다.... 그렇지만,,
이에 대해서 하나의 실무적인 적당한 노무가 가능할 것에 대해서는 Group 의 몇몇에 대해 자문기구가 되는 것이 앞으로의 프로세스 개선에 대해서 적당하기는 합니다....
그렇다면,,
이에 대해서 나머지의 Computer Logic 에 대한 응용 프로그램에 대해서는 Data List 를 사용하지는 못하지만 Data Object 에 대한 Data Structure 에 대해서
어느정도 기대를 걸어볼 수는 있습니다....
왜냐하면,, Data 라는 것에 대해서 그것이 Database 에 수집되어 송출되는 것은 대부분 List 이기 때문에,,
다른 Data 에 대한 노무적인 작업에 대해 Array 와 같은 구조 외의 것을 Information 에 대해서 Stack/Queue/Tree 혹은 Graph 에 대해서 상관되는 부분이 있을 수도
있기 때문입니다.... ^^
그렇지만 Stack 에 대해서는 저장기기의 영역에서 Program 과 같은 부분들에 대해 순차적 Type 의 Data 를 <<일시격 저장>> 에 대해서 사용을 하기 때문에,,
운영체제에서 거의 대부분 Computer Science 에서 말하는 Process Control Block 과 같은 부분들에 대한 <<프로세스 보조저장기기>> 의 하나의 원리로 밖에 사용을 할 수가 없습니다.... ^^;
그렇다면 나머지의 Queue/Tree/Graph 에 대해서 Queue 는 <<송출격 저장>> 에 대해서 사용을 할 수 밖에 없으니,, <<통신처리 보조저장기기>> 의 원리가 될 수 밖에 없습니다...
나머지의 Tree 와 Graph 에 대해서는 원리로써 쓰일 수가 있기에 <<회귀작업의 저장기기>> 에 대해서 쓰일 수가 있습니다....
그렇다면 어느정도의 <<사용자 작업알고리즘>> 에 대해서 Stack 과 Queue 는 사용불가하고,,
Tree 와 Graph 에 대해서 기대를 걸어볼 수가 있는 바가 적어도 어느정도는 있다고 할 수가 있습니다. ^^
그런데,,
<<사용자 작업알고리즘>> 에 대해서 <<회귀작업의 다량성>> 이 이루어질 것에 대해서는 ?짜맞추기의 작업들에 대한 하나의 <<반응형 저장/송출기기>> 라는 것이 가능합니다.... ^^;;
결국에 이러한 것은 1) 애니팡, 2) 큐브 맞추기, 3) 도면 그리기, 등등 에 대해서 일이 있다는 것을 알 수가 있습니다. ^^
그래서,,
결과적으로 설계 중의 다량의 Component 를 통해서 약간의 작업성이 있을 것이 <<Compromise Quest>> 라는 분야분리가 가능합니다....
그래서 이에 대한 Data Tree 혹은 Data Graph 에 대해서는 하나의 사례가 만들어진 것이,,
Data Graph 에 대해서는 그것이 A.I 에 의한 <<Auto LOCAL INFO>> 에 대한 <<회귀적 최적송출 반응의 근거>> 로 쓰이는 것이 <<회귀적 탐색공간>> 이라는 것이 가능하다는 것이 기술적으로 거의 증명이 되었던 듯합니다....
그래서,,
<<회귀적 탐색공간>> 에 대해서는 Local Information 에 대해 <<자료배회에 의한 최적적 대응>> 으로 부터의 <<탐색배회 작업>> 에 Graph 가 쓰이기 때문에,,
Data List 를 좀더 추상적으로 본다면,,
<<사용자 작업알고리즘>>을 설계를 할 일에 대해서는 적당함이 부족한 것이 사실입니다....
그래서,,
나머지의 영역에 대해서는 Tree 밖에 없습니다.... 그런데 Tree 에 대해서는 역시 배회가 기반이 되어야 하지만 <<회귀작업의 다량성>>에 대해서 기본적인 탐색의 기대행위에 대해서는 Graph 에 대해서 <<닫혀있음의 탐색공간>> 이라는 것은 탐색에 대해서 불가결하기 때문에,,
Graph 에 대해서는 <<닫혀있음의 탐색공간>> 을 산정해볼때, Local Machine Information 의 List 를 <<자료적 구조최적화>>에 대해서 작업을 실천할 수는 있지만 적당하지는 않습니다....
그런데,,
Tree 에 대해서는 Data Processing 에 대해서 <<추가/삭제>> 가 이루어지기 때문에 Database 에 대해서 Tree 방식의 Database 가 있다고 한다면 크게 불가능하지는 않습니다....
그래서, 이에 대해서는 <<Document Tree>> 에 대해서 <<인덱스 탐색공간>> 이라는 것이 가능합니다.... ^^ 그리고,, 이에 대한 것이 NoSQL 의 흐름으로 보입니다....
^^
그렇지만 <<Compromise Quest>> 에 대해서 <<Document Tree>>는 하나의 부류일 뿐입니다....
그래서,,
이에 대한 <<Compromise Quest>> 의 나머지 부분은 다음으로 볼 수가 있습니다.... ^^ 1) <<인덱스 탐색공간>> / 2) <<객체 추가/삭제공간>>
그런데 이것이 <<Compromise Quest>> 이기 때문에 이에 대한 것은 3) 도면 그리기.... 등등의 <<사용자 작업공간>> 이 대부분의 정규적인 부분이 된다고 보여집니다....
결국에는 Computer Logic 위에서 <<조립적 객체기반 연결형 설계공간>> 이라는 것이 가능하게 됩니다.... ^^
1234
댓글 0