組み込み系にデータベースは必要か
プログラムの種類といった場合、
開発言語の種類
例えば、java,C,C#,Ruby...
といった、分類の方法とは別に、
そのシステムの使われ方によって、
わける場合があります。
企業内の、業務を管理するシステム
業務システム（基幹業務システム）
・営業管理システム
・生産管理システム
・販売管理システム
・販売管理システム
また、これと、重複する部分がありますが
一般ユーザ（顧客）向けの
サービスシステム
・インタネットによる、Webシステム（ホームページ）
があります。
これらとは、別の分野として、
組み込み系のプログラムがあります。
（エンベデットシステム ）
車を、制御したり、
携帯電話を、制御したり、
あるいは、一般の家電（テレビ、冷蔵庫。。）
に組み込まれたコンピュータ用の
プログラムです。
これらの、プログラムに、データベースは
必要でしょうか？
組み込み系のプログラムの場合
これまでは、いかに、応答性がよく、
信頼性が高い、ということが、大切でした。
（メモリ管理や、ハードインターフェースの管理など。。。）
このため、あまり、データベースに対する、重要度の考えは、
少なかったようです。
しかし、組み込み系のプログラムも、
1つの機器に、組み込まれる、プログラムの量（ステップ数）
も、年々大きくなっています。
たとえば、車、１台の組み込みソフトのステップ数が
10,000,000行になるそうです。
GM Volt の組み込みソフトステップ数は10,000,000行
より。。
このため、今後、ソフト開発の、信頼性、生産性向上の
ためには、データベースの考えが、必然的に入ってきます。
既存のSQLの文法がいいのか、
個別の、組み込み用DBMS(データ管理システム)
が、いいのかは、微妙なところですが。
しかし、DBMSがどのように、なるかは別として、
データを処理するしくみを、汎用的な、しくみ
（インターフェースと手順の規格化）を、
していくと、自然と、SQLのような、構造になります。
できた、規格を、厳格に、SQL文とするかは、別ですが。
また、機能面からみても、用途の多様化により、
ニーズが高くなってきます。
例えば、携帯電話の中には、電話帳が、必ず入っています。
また、その他の、家電の場合でも、
いろいろな、機能モードがあったり、
カレンダ機能があったり、
操作手順にしたがった、メッセージがあったり
あるいは、機器不具合の、障害情報を
内部で管理したり。
内部に、データをもち、管理する場合、
データベース化が、有効です。
また、このようにすることで、
将来への、汎用性、拡張性も、向上します。
データを変えるだけで、お客さんメニューと
機能が、変わるような、プログラム構造に
なれば、保守、運用の楽になります。
大きな、階層で、機能分割することで、
プログラムの柔軟性が、上がります。
（単なる部品化とは、異なりますよ）
プログラム進化論では、ないですが。
このような点から、組み込み系の人も、一度、
SQLにふれてのも、有効かと、思います。
■まとめ
組み込み系にデータベースは必須ではありませんが、
勉強することは、決して損ではありません。
開発言語の種類
例えば、java,C,C#,Ruby...
といった、分類の方法とは別に、
そのシステムの使われ方によって、
わける場合があります。
企業内の、業務を管理するシステム
業務システム（基幹業務システム）
・営業管理システム
・生産管理システム
・販売管理システム
・販売管理システム
また、これと、重複する部分がありますが
一般ユーザ（顧客）向けの
サービスシステム
・インタネットによる、Webシステム（ホームページ）
があります。
これらとは、別の分野として、
組み込み系のプログラムがあります。
（エンベデットシステム ）
車を、制御したり、
携帯電話を、制御したり、
あるいは、一般の家電（テレビ、冷蔵庫。。）
に組み込まれたコンピュータ用の
プログラムです。
これらの、プログラムに、データベースは
必要でしょうか？
組み込み系のプログラムの場合
これまでは、いかに、応答性がよく、
信頼性が高い、ということが、大切でした。
（メモリ管理や、ハードインターフェースの管理など。。。）
このため、あまり、データベースに対する、重要度の考えは、
少なかったようです。
しかし、組み込み系のプログラムも、
1つの機器に、組み込まれる、プログラムの量（ステップ数）
も、年々大きくなっています。
たとえば、車、１台の組み込みソフトのステップ数が
10,000,000行になるそうです。
GM Volt の組み込みソフトステップ数は10,000,000行
より。。
このため、今後、ソフト開発の、信頼性、生産性向上の
ためには、データベースの考えが、必然的に入ってきます。
既存のSQLの文法がいいのか、
個別の、組み込み用DBMS(データ管理システム)
が、いいのかは、微妙なところですが。
しかし、DBMSがどのように、なるかは別として、
データを処理するしくみを、汎用的な、しくみ
（インターフェースと手順の規格化）を、
していくと、自然と、SQLのような、構造になります。
できた、規格を、厳格に、SQL文とするかは、別ですが。
また、機能面からみても、用途の多様化により、
ニーズが高くなってきます。
例えば、携帯電話の中には、電話帳が、必ず入っています。
また、その他の、家電の場合でも、
いろいろな、機能モードがあったり、
カレンダ機能があったり、
操作手順にしたがった、メッセージがあったり
あるいは、機器不具合の、障害情報を
内部で管理したり。
内部に、データをもち、管理する場合、
データベース化が、有効です。
また、このようにすることで、
将来への、汎用性、拡張性も、向上します。
データを変えるだけで、お客さんメニューと
機能が、変わるような、プログラム構造に
なれば、保守、運用の楽になります。
大きな、階層で、機能分割することで、
プログラムの柔軟性が、上がります。
（単なる部品化とは、異なりますよ）
プログラム進化論では、ないですが。
このような点から、組み込み系の人も、一度、
SQLにふれてのも、有効かと、思います。
■まとめ
組み込み系にデータベースは必須ではありませんが、
勉強することは、決して損ではありません。
データベースから、システムを考える
システムを作る時、
ほとんどの場合、
なんらかの、データを扱います。
そこで、
データの流れ
データの変化
という、観点で考えると、システムが分かりやすくなります。
そして、
どんな、情報（データ）が、必要か
と考えることで、処理の内容が、見えてきて、
システムの全貌が、見えてきます。
たとえば、
身近なところでは、
お小遣いの管理
毎月、使える、お小遣いがありますよね。
そして、それを、毎日、なにかに使います。
本を買ったり、お酒を、買ったり。。。
すると、毎月の、お小遣いが、減っていきます。
しかし、月末になって、もし、あまった場合には、
貯金に、回すことができます。
また、逆に、予期しない、出費があった場合、
お小遣いが、たりなくなり、貯金から、きりくずさないと
いけないかもしれません。
このような、処理を
データの要素をまとめ、
データの操作として、決めていくと、
システムの内容が、見やすくなります。
そして、データの操作を行うところが
SQL文となります。
テーブルの構成を決め、
実際にテーブルを作るのも、SQL文になります。
また、このように進めていくと、
一番、興味のある、
「お金が、いくら貯まるか」
に、考えが、集まるので、
システムが、見えやすくなります。
それに、もし、このシステムが
「お小遣いを管理する」
ものではなく
「お金を、貯める」
のが、目的であったら、
いろいろな、アイディア（手段）が、
浮かびますよね。
それに、参加者（家族）が、
たくさんいて、共通の目標が、決まると、
もっと、システムがつくりやすくなります。
たとえば、
「２年間で、６５万貯めて、家族で、ハワイに行く」
などであれば、みんなの協力で、
システムも、活用され、
きっと、
目標を達成することが、できるでしょう。
このように、システムを、データから、考える方法を、
DOA 【Data Oriented Approach】（データ中心アプローチ）
といいます。
解りやすく、シンプルに、現象を、表現できれば、
いいので。
データ中心アプローチの勉強に、
お小遣いの動きを、調査してみては、
いかがですか？
来月は、貯金が、少し、増えているかもしれませんね。
ほとんどの場合、
なんらかの、データを扱います。
そこで、
データの流れ
データの変化
という、観点で考えると、システムが分かりやすくなります。
そして、
どんな、情報（データ）が、必要か
と考えることで、処理の内容が、見えてきて、
システムの全貌が、見えてきます。
たとえば、
身近なところでは、
お小遣いの管理
毎月、使える、お小遣いがありますよね。
そして、それを、毎日、なにかに使います。
本を買ったり、お酒を、買ったり。。。
すると、毎月の、お小遣いが、減っていきます。
しかし、月末になって、もし、あまった場合には、
貯金に、回すことができます。
また、逆に、予期しない、出費があった場合、
お小遣いが、たりなくなり、貯金から、きりくずさないと
いけないかもしれません。
このような、処理を
データの要素をまとめ、
データの操作として、決めていくと、
システムの内容が、見やすくなります。
そして、データの操作を行うところが
SQL文となります。
テーブルの構成を決め、
実際にテーブルを作るのも、SQL文になります。
また、このように進めていくと、
一番、興味のある、
「お金が、いくら貯まるか」
に、考えが、集まるので、
システムが、見えやすくなります。
それに、もし、このシステムが
「お小遣いを管理する」
ものではなく
「お金を、貯める」
のが、目的であったら、
いろいろな、アイディア（手段）が、
浮かびますよね。
それに、参加者（家族）が、
たくさんいて、共通の目標が、決まると、
もっと、システムがつくりやすくなります。
たとえば、
「２年間で、６５万貯めて、家族で、ハワイに行く」
などであれば、みんなの協力で、
システムも、活用され、
きっと、
目標を達成することが、できるでしょう。
このように、システムを、データから、考える方法を、
DOA 【Data Oriented Approach】（データ中心アプローチ）
といいます。
解りやすく、シンプルに、現象を、表現できれば、
いいので。
データ中心アプローチの勉強に、
お小遣いの動きを、調査してみては、
いかがですか？
来月は、貯金が、少し、増えているかもしれませんね。
長所を、伸ばしましょう
長所を、伸ばしましょう
人は、どうしても、人の、欠点に、目がいってしまいます。
これは、あなたが、想定しているものと、
違う結果に、対する、拒否反応によるものです。
なんで、そうなの。
なんで、できないの。
となって、しまいます。
このことが、気になると、せっかくの、
いいところが、気づかれずに、されてしまう
ことがあります。
完璧を、目指すのも、大切ですが、
成功した、あなたの長所を、大切にして、
伸ばしていきましょう。
iPhoneから送信
人は、どうしても、人の、欠点に、目がいってしまいます。
これは、あなたが、想定しているものと、
違う結果に、対する、拒否反応によるものです。
なんで、そうなの。
なんで、できないの。
となって、しまいます。
このことが、気になると、せっかくの、
いいところが、気づかれずに、されてしまう
ことがあります。
完璧を、目指すのも、大切ですが、
成功した、あなたの長所を、大切にして、
伸ばしていきましょう。
iPhoneから送信