リレーショナル データベース管理システムの基本概念の機能。 データベースとサブデータベース
データ バンクは、電子コンピューターを使用したデータの集中蓄積とその使用を目的とした一連のデータベース、ソフトウェア、言語、その他のツールとして理解されます。
データ バンクには、1 つ以上のデータベース、データベース ディレクトリ、データベース管理システム (DBMS)、さらにクエリとアプリケーション プログラムのライブラリが含まれます。
データ バンクは、大量の情報を保存し、必要な情報や文書をすぐに見つけられるように設計されています。
データ バンクは、パーソナル コンピューターからスーパーコンピューターまで、あらゆる容量のサブスクライバー システム内に作成されます。 しかし、最大のデータバンクであってもその能力には限界があります。 したがって、オンライン銀行は、科学、技術、製品の特定の分野の情報収集に特化しています。 銀行の中核はデータベースと知識ベースです。 データベースは、情報を保存するために設計された組織化された構造です。 データと情報は相互に関連する概念ですが、同一ではありません。この定義には一貫性がないことに注意してください。 現在、ほとんどのデータベース管理システム (DBMS) では、構造内にデータだけでなくメソッド (つまり、 プログラムコード)、これを利用して、消費者または他のソフトウェアおよびハードウェア システムとの対話が行われます。 したがって、最新のデータベースにはデータだけでなく情報も保存されていると言えます。
BnD は 特別な手段により、ユーザーがデータ (DBMS) を操作しやすくなります。
一元的なデータ管理には、従来のファイル システムに比べて次のような利点があります。
— データストレージの冗長性の削減。
− 情報システムの開発、運用、最新化にかかる労働集約度を軽減する。
ユーザーとしてデータに便利にアクセスできるようにする
データ専門家とエンドユーザーの両方。
BnD の基本要件:
— 表示の適切性 対象分野(完全性、完全性、および - データの一貫性、情報の関連性;
- 異なるカテゴリーのユーザー間で対話する機能、データアクセスの効率性。
— フレンドリーなインターフェース、短いトレーニング時間。
- 機密性を確保し、さまざまなユーザーのデータへのアクセスを制限します。
— ストレージとデータ保護の信頼性。
データバンクという用語の定義は、政令で承認されたデータベースおよびデータバンクの国家会計および登録に関する暫定規則に規定されています。 ロシア連邦 96 年 2 月 28 日付け、No. 226、第 2 条 (SZ RF、1996 年、No. 12、第 1114 条)
当初 (60 年代初頭) はファイル ストレージ システムが使用されていました。 少量のデータと大量の計算を特徴とする主に工学的な問題を解決するために、データはプログラムに直接保存されました。 適用済み シーケンシャル方式データ構成には、高い冗長性、同一の論理構造と物理構造、そして完全なデータ依存性がありました。 大量のデータと少数の計算を特徴とする経済的および管理的タスク (管理情報システム - MIS) の出現により、このデータの編成は非効率的であることが判明しました。 データの順序付けが必要でしたが、これは、次の 2 つの基準に従って実行できることが判明しました。 ストレージ（データベース）。 当初は情報配列が使用されていましたが、すぐにデータベースの優位性が明らかになりました。 データのみを保存するファイルの使用は、1959 年に Mac Gree によって提案されました。 このようなファイルへのアクセス (ランダム アクセスを含む) 方法が開発されましたが、物理構造と論理構造はすでに異なっており、論理表現を変更せずにデータの物理的位置を変更できました。
1963 年に、S. Bachman はネットワーク データ モデルを使用して最初の産業用 IDS データベースを構築しました。このデータベースは依然としてデータの冗長性と 1 つのアプリケーションのみに使用するという特徴がありました。 データには、適切なソフトウェアを使用してアクセスしました。 1969 年に、ネットワーク データ モデルの標準セット CODASYL を作成するグループが結成されました。
実際に使い始めた 近代建築データベース。 アーキテクチャは、任意の要素を別の要素で置き換えることができる構造のタイプ (一般化) として理解され、その入力および出力の特性は最初の要素と同一です。 データベース テクノロジーの開発は、1970 年に M. Codd によって提案されたリレーショナル データ モデルのパラダイムによって大きな進歩を遂げました。 パラダイムは、現実の本質的な特徴を反映する概念体系に具体化された科学理論として理解されます。 これで、同じ物理データから論理構造を取得できるようになりました。 同じ物理データにアクセスできる可能性がある さまざまなアプリケーションさまざまな道に沿って。 となりました 可能な提供データの整合性と独立性。
70 年代の終わりには、物理的および論理的な独立性、データ セキュリティを提供し、データベース言語を開発した最新の DBMS が登場しました。 過去 10 年間の特徴は、分散型データベースとオブジェクト指向データベースの出現であり、その特徴は自動設計ツールの適用とデータベースの知的化によって決定されます。
データベースの概念と密接に関連しているのは、データベース管理システムの概念です。これは、新しいデータベースの構造を作成し、コンテンツを入力し、コンテンツを編集し、情報を視覚化するために設計された一連のソフトウェア ツールです。 データベース情報の視覚化とは、所定の基準に従って表示されるデータを選択し、それらの順序、設計、およびその後の出力デバイスへの出力または通信チャネルを介した送信を意味します。
世の中には数多くのデータベース管理システムがあります。 オブジェクトが異なれば動作も異なり、ユーザーに提供するものは異なりますが、 さまざまな機能ほとんどの DBMS は、確立された単一の基本概念セットに依存しています。 これにより、1 つのシステムを検討し、その概念、技術、およびメソッドを DBMS クラス全体に一般化する機会が得られます。
DBMS は、情報のストレージを次のような便利な方法で編成します。
ブラウズ、
補充し、
変化、
必要な情報を探して、
任意の選択をする
任意の順序で並べ替えます。
データベースの分類:
a) 保存された情報の性質に応じて:
事実（カードインデックス）、
ドキュメンタリー（アーカイブ）
b) データ保存方法に応じて：
集中管理 (1 台のコンピュータに保存)、
分散型 (ローカルおよびグローバルのコンピューター ネットワークで使用)。
c) データ組織構造に従って:
表形式 (リレーショナル)、
階層的、
最新の DBMS では、テキストやグラフィック情報だけでなく、サウンドの断片やビデオ クリップさえも含めることができます。
DBMS は使いやすいため、プログラミングを行わずに組み込み関数のみを使用して新しいデータベースを作成できます。 DBMS は、データの正確性、完全性、一貫性を保証するだけでなく、 簡単にアクセスできる彼らへ。
人気の DBMS - FoxPro、Access Windows用、 逆説。 それほど複雑ではないアプリケーションの場合は、DBMS の代わりに、次の機能を実行する情報検索システム (IRS) が使用されます。
大量の情報を保存する。
必要な情報を素早く検索できます。
保存された情報の追加、削除、および変更。
それを人間にとって使いやすい形で出力します。
データベース内の情報は、関連するデータ要素のグループである個々のレコードに構造化されています。 レコード間の関係の性質によって、データベース編成の 2 つの主なタイプ (階層型とリレーショナル型) が決まります。
データベースにデータが存在しない (空のデータベース) 場合でも、それは本格的なデータベースです。 この事実には方法論的な意味があります。 データベースにはデータがありませんが、情報はまだ存在します。これがデータベースの構造です。 データを入力してデータベースに保存するためのメソッドを定義します。 データベースの最も単純な「非コンピュータ」バージョンはビジネス ダイアリーで、暦日ごとに 1 ページが割り当てられます。 たとえ一行も書かれていないとしても、日記とは明確に区別された構造を持っているので、それは日記であることには変わりない。 ノート、ワークブック、その他の文具製品。
データベースにはさまざまなオブジェクトを含めることができますが、データベースの主なオブジェクトはテーブルです。 最も単純なデータベースには少なくとも 1 つのテーブルがあります。 したがって、最も単純なデータベースの構造は、そのテーブルの構造と同じです。
現在、システム数は急速に増加しています。 eコマース(SEC)。 電子商取引にはさまざまなものがあります 特徴的な機能、彼女を以前の誰ともはっきりと区別しています 既知の方法インターネットの優れた通信特性による古典的な商取引
電子商取引システムには、複数のビジネス アプリケーションにわたるビジネス トランザクションを調整し、さまざまなソースから個々の情報を抽出して、それらをタイムリーかつシームレスな方法で顧客に配信できる機能が必要です。 必要な情報, - すべては単一ユーザーの Web リクエストに基づいています。
SEC には、従来の商取引システム (通常の店舗、スーパーマーケット、証券取引所など) とは異なる一連の特定の特性があります。 同時に、最適化問題の古典的な定式化では SEC でプロセス モデルを構築および分析するときに、これらの特性を考慮する必要があります。 最適制御ディスクリートシステムには適していません。 SEC の特性は次のとおりです。厳密に規制された作業スケジュールがある従来のシステムとは異なり、動作時間は無制限です。 訪問者の流れは時間の経過とともに均等に分散されていると言えます。 SEC の従来のシステム (これは特に B2C クラスのシステムに典型的です) とは異なり、訪問者は購入を行うためだけでなく、商品の品揃え、価格、支払い条件、配送などの情報を受け取るためにも訪れます。
同時に、古典的なシステムは、訪問者が購入者になる可能性が非常に高いという特徴があります。 したがって、次のことが考えられます。 さまざまなモデル SEC の機能の有効性を評価するための方法: 訪問者数に対する購入者数の比率、SEC の活動の影響、および フィードバックアプリケーションの入力フローに。
SEC では、多くの訪問者が情報を得るために何度も訪問し、すべての条件に満足して初めて購入に至るのが一般的です。
SEC は、同時にかなり多くの訪問者にサービスを提供できます。 この特性は、SEC のソフトウェアおよびハードウェアの機能によってのみ制限されます。 つまり、SEC の場合、ユーザーの観点からは、サービスを待っているキューは存在しません。 これは、完全または部分的に自動化された SEC に特に当てはまります。
SEC では、仮想カートに商品を入れた訪問者が購入せずにシステムを離れるケースが考えられます (商品を盗むことは不可能なので、すべての商品がシステムに残るのは当然です)。 古典との類似点を描く 取引システム繰り返しになりますが、訪問者が店舗に入って、最初に商品をカートいっぱいに積み込み、次にすべてを降ろして店を出る状況を想像するのは困難です。 SEC では、制御因子のセットが最適でない (または最適に準じている) 場合にこのケースが発生する可能性があります。
データベース管理システムを使用すると、大量の情報を組み合わせて処理、並べ替え、特定の基準に基づいた選択などを行うことができます。
最新の DBMS では、テキストやグラフィック情報だけでなく、サウンドの断片やビデオ クリップさえも含めることができます。 DBMS は使いやすいため、プログラミングを行わずに組み込み関数のみを使用して新しいデータベースを作成できます。 DBMS は、データの正確性、完全性、一貫性を保証します。
1.2 リレーショナルデータベース
リレーショナル DBMS (RSDBMS、またはリレーショナル データベース管理システム、RDBMS) は、リレーショナル データベースを管理する DBMS です。
関係の概念は、データベース システムの分野で有名な英国の専門家、エドガー コッドの発展に関連しています。
これらのモデルは、データ構造の単純さ、使いやすい表形式の表現、およびデータ処理にリレーショナル代数とリレーショナル微積分の正式な装置を使用できる機能によって特徴付けられます。
リレーショナル モデルは、2 次元テーブルの形式でデータを編成することに重点を置いています。 各関係テーブルは次のとおりです。 二次元配列そして次のような特性を持っています。
– 各テーブル要素は 1 つのデータ要素です。
– テーブル内のすべての列は同種です。つまり、列内のすべての要素が同じタイプ (数値、文字など) を持ちます。
– 各列には一意の名前が付いています。
– テーブル内に同一の行はありません。
– 行と列の順序は任意です。
リレーショナル DBMS の基本概念は次のとおりです。1) 属性。 2）人間関係。 3) タプル。
したがって、データベースはテーブルの集合にすぎません。 RDBS およびレコード指向システムは、B ツリー標準または ISAM (Indexed Sequential Access Method) に基づいて編成されており、 標準システム、最も現代で使用されている ソフトウェア製品。 ほとんどの B-Tree および ISAM ソフトウェア実装にはほぼ完全に存在しない、テーブルの組み合わせによるデータ間の関係の定義を可能にするために、SQL (IBM)、Quel (Ingres)、RDO (Digital Equipment) などの言語が使用されます。現在では業界標準の SQL 言語となり、すべてのリレーショナル DBMS メーカーによってサポートされています。
SQL のオリジナル バージョンは、データベース上で操作を実行するために設計されたインタープリタ型言語です。 SQL 言語は、70 年代初頭に、当時新しいリレーショナル理論に基づいてデータベースと対話するためのインターフェイスとして作成されました。 実際のアプリケーション通常、SQL コードを生成し、それを ASCII テキストとして DBMS に送信する他の言語で書かれています。 また、実際のリレーショナル (リレーショナルだけではない) ほぼすべてのシステムには、現在 SQL2 (または SQL-92) という名前で最新版として知られている ANSI SQL 標準の実装に加えて、以下のものが含まれていることにも注意してください。 追加の拡張機能たとえば、クライアント/サーバー アーキテクチャやアプリケーション開発ツールのサポートなどです。
テーブルの行は、データベースに事前に知られているフィールドで構成されています。 ほとんどのシステムは新しいデータ型を追加できません。 テーブルの各行は 1 つのレコードに対応します。 新しい行が削除または挿入されると、特定の行の位置が変わる可能性があります。
要素を一意に識別するには、テーブル内での要素の一意性を保証するフィールドまたはフィールドのセットに要素を関連付ける必要があります。 このフィールドは主キー ( 主キー) テーブルであり、多くの場合は数値です。 あるテーブルに別のテーブルの主キーが含まれている場合、これにより、異なるテーブルの要素間の関係を整理できます。 このフィールドは外部キーと呼ばれます。
1 つのテーブルのすべてのフィールドには、あらかじめ一定数のフィールドが含まれている必要があるため、 特定のタイプを使用して、要素の個々の特性を考慮した追加のテーブルを作成する必要があります。 外部キー。 このアプローチでは、データベース内に複雑な関係を作成することが非常に複雑になります。 リレーショナル データベースのもう 1 つの大きな欠点は、情報の操作と関係の変更が非常に複雑であることです。
リレーショナル データベースには欠点があると考えられていますが、次のような利点もあります。
異なるプログラムを使用してテーブルを分割する。
エラーの「戻りコード」を拡張しました。
クエリ処理の高速化（SELECTコマンド） SQL言語; 選択の結果は、指定された基準を満たすフィールドを含むテーブルになります)。
コンセプトそのもの オブジェクトデータベースデータは非常に複雑であり、プログラマーによる真剣で長期にわたるトレーニングが必要です。
大量のデータを扱う場合は比較的高速です。
さらに、世界中ですでに多額の資金がリレーショナル DBMS に投資されています。 多くの組織は、オブジェクト データベースへの移行に伴うコストがそれだけの価値があるかどうか確信が持てません。
したがって、多くのユーザーは、リレーショナル データベースを完全に放棄することなくオブジェクト データベースの利点を活用できる、組み合わせたアプローチに興味を持っています。 そのような解決策は実際に存在します。 リレーショナル データベースからオブジェクト データベースへの移行に費用がかかりすぎる場合は、後者をリレーショナル DBMS への拡張および追加として使用する方が、費用対効果の高い代替手段となることがよくあります。 侵害ソリューションを使用すると、オブジェクトとリレーショナル テーブルの間のバランスを維持できます。
オブジェクトリレーショナルアダプター - えーこの方法には、プログラム オブジェクトを自動的に割り当て、リレーショナル データベースに格納する、いわゆるオブジェクト リレーショナル アダプタの使用が含まれます。 オブジェクト指向アプリケーションは、通常の DBMS ユーザーと同じように動作します。 多少のパフォーマンスの低下はありますが、このオプションを使用すると、プログラマはオブジェクト指向の開発に完全に集中できます。 さらに、企業内のすべてのアプリケーションは、引き続きリレーショナル形式で保存されたデータにアクセスできます。
GemStone Systems の GemStone などの一部のオブジェクト DBMS は、それ自体が強力なオブジェクト リレーショナル アダプターとして機能し、オブジェクト指向アプリケーションがリレーショナル データベースにアクセスできるようにします。
Hewlett-Packard の odapter for Oracle などのオブジェクト リレーショナル アダプターは、オブジェクト指向アプリケーションとリレーショナル データベースを統合するミドルウェアなど、多くの分野で役立ちます。
オブジェクト リレーショナル ゲートウェイ - pこの方法を使用する場合、ユーザーは OODBMS 言語を使用してデータベースと対話し、ゲートウェイはこの言語のすべてのオブジェクト指向要素をリレーショナル コンポーネントに置き換えます。 この場合も生産性の面で代償を払う必要があります。 たとえば、ゲートウェイはオブジェクトを一連の関係に変換し、オブジェクトの元の識別子 (OID) を生成して、これをリレーショナル データベースに渡す必要があります。 その後、ゲートウェイは、RDBMS インターフェイスが使用されるたびに、データベース内で見つかった OID を、RDBMS に格納されている対応するオブジェクトに変換する必要があります。
考慮された 2 つのアプローチのパフォーマンスは、リレーショナル データベースへのアクセス方法によって異なります。 各 RDBMS は、データ マネージャー層とストレージ マネージャー層の 2 つの層で構成されます。 1 つ目は SQL 言語でステートメントを処理し、2 つ目はデータをデータベースに表示します。 ゲートウェイまたはアダプターは、データ層 (つまり、SQL を使用した RDBMS へのアクセス) とメディア層 (プロシージャ呼び出し) の両方と対話できます。 低レベル）。 最初のケースのパフォーマンスははるかに低くなります (たとえば、ゲートウェイとして機能できる Hewlett-Packard OpenODB システムは、高レベルでのみサポートします)。
ハイブリッド DBMS - eもう 1 つの解決策は、従来の表形式のデータとオブジェクトの両方を格納できるハイブリッド オブジェクト リレーショナル DBMS を作成することです。 多くのアナリストは、将来はこのようなハイブリッド データベースにあると信じています。 主要なリレーショナル DBMS ベンダーは、自社製品にオブジェクト指向機能を追加し始めています (または計画しています)。 特に、Sybase と Informix は、DBMS の将来のバージョンでオブジェクト サポートを導入することを計画しています。 独立系企業も同様の開発を行う予定だ。 たとえば、Shores 社は、Oracle8 DBMS にオブジェクト指向ツールを装備する準備を進めており、1996 年末にリリースされる予定です。
一方、Object Design などのオブジェクト DBMS ベンダーは、オブジェクト指向データベースが近い将来にリレーショナル DBMS に置き換わることはないと認識しています。 そのため、リレーショナルおよび階層データベース、またはさまざまな種類のインターフェイスをサポートするゲートウェイを作成する必要があります。その典型的な例は、Ontos/DB OODB と組み合わせて使用される Ontos の Ontos Integration Server オブジェクト リレーショナル インターフェイスです。
1.3 多次元データベース
特別なストレージ構成であるキューブを備えた強力なデータベースにより、ユーザーは大量のデータを分析できます。 多次元データベースを使用すると、 高速ファクト、ディメンション、事前計算された集計のコレクションとして保存されたデータを操作します。
に基づいた特殊な DBMS では、 多次元表現データの場合、データはリレーショナル テーブルの形式ではなく、順序付けられた多次元配列の形式で編成されます。
ハイパーキューブ - データベースに保存されるすべてのセルは同じ次元を持つ必要があります。つまり、最も完全な測定基準にある必要があります。
ポリキューブ - 各変数は独自のディメンションのセットとともに保存され、関連する処理の複雑さはすべてシステムの内部メカニズムに転送されます。
オンライン分析処理システムで多次元データベースを使用すると、次のような利点があります。
ハイパフォーマンス。 このクラスに属する製品には、通常、多次元データベース サーバーが含まれています。 分析プロセスのデータは多次元構造からのみ選択されます。この場合、多次元データベースは非正規化されており、事前に集計された指標が含まれており、要求されたセルへの最適化されたアクセス
データの検索と取得は、リレーショナル データベースの多次元概念ビューを使用するよりもはるかに高速に実行されます。多次元 DBMS を使用する場合、アドホック クエリに対する平均応答時間は、通常、リレーショナル データベースの場合よりも 1 ～ 2 桁短くなります。正規化されたデータスキーマを備えた DBMS
構造とインターフェイスは分析クエリの構造に最もよく一致します。 分析者はフラット テーブルでの操作に慣れているため、この方法は人間のメンタル モデルにより似ています。 2 次元平面で立方体を一方向または別の方向に切断することにより、選択した尺度に対する任意の量のペアの相互依存性を簡単に取得できます。 たとえば、製品の製造コスト（尺度）が時間の経過とともにどのように変化したか（次元）、セクション、作業場、生産施設ごとに分類したもの（別の次元）
多次元 DBMS は、情報モデルにさまざまな組み込み関数を組み込むタスクに簡単に対処できると同時に、客観的なデータを提供します。 既存の制限 SQL 言語では、リレーショナル DBMS に基づいてこれらのタスクを実行することが非常に困難になり、場合によっては不可能になります。
MOLAP は独自の多次元データベースでのみ動作し、多次元 DBMS 用の独自のテクノロジに基づいているため、最も高価です。 これらのシステムは、OLAP 処理のフル サイクルを提供し、サーバー コンポーネントに加えて独自の統合クライアント インターフェイスを含むか、外部スプレッドシート プログラムを使用してユーザーと通信します。 このようなシステムを保守するには、システムのインストール、保守、およびエンド ユーザー向けのデータ ビューの作成を行う特別なスタッフの従業員が必要です。
MOLAP モデルのその他の欠点は次のとおりです。
大規模なデータベースの操作は許可されません。 現在、実際の制限は 10 ～ 20 ギガバイトです。 さらに、非正規化と事前実行された集計により、多次元データベースの 20 ギガバイトは、原則として (Codd によれば) 元の詳細データの 2.5 ～ 100 分の 1 の量、つまりせいぜい数ギガバイトに相当します。 。
リレーショナル メモリと比較すると、外部メモリの使用効率が非常に低くなります。 ハイパーキューブ セルは、論理的に順序付けられた配列 (固定長ブロック) の形式で格納され、そのようなブロックがインデックス付きの最小単位となります。 多次元 DBMS ブロックには何も含まれていませんが、 一定の値、が保存されていない場合、これは問題を部分的にしか解決しません。 データは順序付けられた方法で保存されるため、未定義の値が常に完全に削除されるわけではなく、ソート順序によってデータが可能な限り最大の連続グループに編成される場合にのみ削除されます。 ただし、クエリで最もよく使用される並べ替え順序は、存在しない値を最大限に排除するために並べ替えるべき順序ではない場合があります。 したがって、多次元データベースを設計する場合、多くの場合、速度 (これが多次元 DBMS を選択する最初の利点の 1 つであり、主な理由です) または外部メモリ (ただし、前述したように、 最大サイズ多次元データベースには制限があります)
データを記述および操作するためのインターフェースや言語には統一された標準がありません
読み込みメカニズムとしてよく使用されるデータ複製はサポートされていません。 したがって、多次元 DBMS の使用は、次の条件下でのみ正当化されます。
分析用のソース データの量はそれほど大きくありません (数ギガバイト以下)。つまり、データ集約のレベルは非常に高いです。
情報ディメンションのセットは安定しています (ディメンションの構造を変更すると、ほとんどの場合、ハイパーキューブの完全な再構築が必要となるため)。
規制されていないリクエストに対するシステムの応答時間は、最も重要なパラメーターです。
ハイパーキューブ セルで次元間計算を実行するには、カスタムの数式や関数を作成する機能など、複雑な組み込み関数を広範囲に使用する必要があります。
2. 実践編
2.1 問題の記述
2.1.1 問題解決の目的
施設の修繕作業の実行に関連する活動を行う Stroy-design LLC 社の経営陣は、クライアントに請求書を迅速に提供するために、実行された作業コストの計算を自動化したいと考えています。 これにより、決済時間を短縮し、人的ミスを回避し、提供されるサービスに対する顧客満足度を向上させることができます。 したがって、実行された作業のコストを計算し、支払いのための請求書を作成することが決定されました。この請求書には、作業の名前、実行された作業量、生産単位あたりの価格、および作業のコストが含まれる必要があります。 MS Excel ソフトウェア環境で毎月解決されるタスクは、「完了した作業のコストの計算」と呼ばれます。
この問題を解決する目的は、クライアントに詳細な請求書を迅速に提供するための作業コストをタイムリーに計算することです。
2.1.2 問題の状況
入力 運行情報
「実行された作業コストの計算」という文書が使用されます。これには、作業の名前、実行された作業量、製品単位あたりの価格（ルーブル）、作業コスト（ルーブル）、最後の 2 つの詳細が含まれています。詳細を計算して計算する必要があります。 それをもとに、以下のような画面フォームが作成されます。
|
名前 |
単位 |
音量 |
価格 |
|
|
チー |
C i |
シ |
||
条件付き永続情報（参考）組織の価格リストとして機能し、次の詳細（条件付き形式）が含まれます：作品名、生産単位あたりの価格（摩擦）。 それをもとに、以下のような画面フォームが作成されます。
価格表
|
役職 |
生産単位あたりの価格、こすれ。 |
表中のラテン文字は、対応する計算式の要素を示します。
結果として次の詳細が記載された請求書を受け取る必要があります: 作業名、製品単位あたりの価格 (ルーブル)、実行された作業量、作業コスト (ルーブル)、請求書番号 (自動入力)。 顧客の名前と日付は手動で入力されます。 情報は次の文書で提供されます。
作成される文書「請求書」の構造
|
ストロイサービスLLC |
||||||||||
|
アカウントなし。 |
||||||||||
|
日付 |
20__ |
|||||||||
|
クライアントのフルネーム |
||||||||||
|
№ |
名前 |
単位 |
音量 |
生産単位あたりの価格、こすれ。 |
価格 |
|||||
|
電池の交換 |
パソコン。 |
|||||||||
|
壁紙ステッカー |
平方メートル |
|||||||||
|
パイプ交換 |
||||||||||
|
寄木細工の床 |
平方メートル |
|||||||||
|
合計： |
ΣS i |
|||||||||
|
バット： |
N |
|||||||||
|
付加価値税を含む価格: |
SN |
|||||||||
|
Ch. 会計士 |
||||||||||
さらに、分析用の表に含まれる情報は、図の形式で提示する必要があります。
テクノロジーでは、VLOOKUP または VIEW 関数を使用して「請求書」ドキュメントを自動生成するためのテーブル間の接続を整理します。
2.2. 問題を解決するためのコンピュータモデル
2.2.1. 問題を解決するための情報モデル
ソース文書と結果の文書間の関係を反映した情報モデルを図に示します。 2.
2.2.2. 問題を解決するための分析モデル
書類を受け取るには」実行コストの計算
作品 » 次の指標を計算する必要があります。
仕事のコスト、摩擦。
VAT、こすります。
消費税を含む金額、摩擦。
計算は次の式を使用して実行されます。
S i = C i ∙Q i ,
N = ΣS i ∙ 0.18 ,
SN = ΣS i + N、
どこ シ
- 価格 私番目の作品。 C i
-
の価格 私-番目の生産単位。 Q i -実行される作業量 私番目の作品。 N- 付加価値税;SN- VAT を含む価格。
2.2.3. MS Excelの問題を解決するテクノロジー
MS Excelを使用して問題を解決する
Excel を呼び出します:
「開始」ボタンをクリックします。
メインメニューで「プログラム」コマンドを選択します。
メニューにある マイクロソフトオフィス「MS Excel」を選択します。
「シート 1」の名前を「価格表」に変更します。
で選択してください コンテキストメニュー「名前の変更」コマンドを選択し、マウスの左ボタンをクリックします。
「Enter」キーを押します。
表のタイトルに「価格表」を入力します。
キーボードで「価格表」と入力します。
4. タイトルの書式を設定します。
米。 2. セルのグループを選択する例
「ホーム」タブのツールバーで「配置」セクションを選択し、 ボタンをクリックします。
5. 長い見出しを入力できるようにセル A2:B2 をフォーマットします。
セル A2:B2 を選択します。
ツールバーの「ホーム」メニューの「セルの書式設定」セクションにある「配置」コマンドを実行します。
「配置」タブを選択します。
「表示」オプショングループで、「ワードラップ」オプションをチェックします（図3）。
米。 3. セルに長い単語を入力する場合の単語のハイフネーションの設定
ヘッダー
「OK」をクリックします。
6. セル A2:B2 に図に示されている情報を入力します。 4.
7. セル A3:A8 の書式を設定してテキスト文字を入力します。
セル A3:A8 を選択します。
「ホーム」メニューのツールバーで「セル」を選択し、「書式設定」項目で「セルの書式設定」コマンドを選択します。
「数値」タブを選択します。
「テキスト」形式を選択します（図5）。
「OK」をクリックします。
米。 5. セル形式の選択
8. セル範囲 B3:B8 に対して手順 9 を繰り返し、「数値」形式を選択します。
9. 初期データを入力します (図 6)。
米。 6.「価格表」テーブルビュー
10. セルのグループに名前を付けます。
セル A3:B8 を選択します。
「式」メニューの「定義名」セクションで「名前の割り当て」コマンドを選択します (図 7)。
米。 7.「名前作成」画面の見方
「OK」ボタンをクリックします。
11.「シート 2」の名前を「作業コストの計算」に変更します (手順 2 と同様)。
12. 「実行された作業コストの計算」表を作成します (ステップ 3 ～ 7、8 と同様) (図 8)。
米。 8. テーブルビュー「作業コストの計算」
13. 「作品名」と「製品の単位あたりの価格、こすり」の列を入力します。
セル A3 をアクティブにします。
「データ」メニューで「データ検証」コマンドを選択し、「データタイプ」フィールドで「リスト」を選択します。
「ソース」フィールドに値を入力し、「価格表」の範囲 A3:A8 を強調表示します (図 9)。
米。 9. 支払者のリストの設定
「OK」ボタンをクリックします。
列 A の各セル (「ジョブ名」) にリストからジョブの名前を入力するには、セル A3 をアクティブにし、右側のマーカーにカーソルを置きます。 下の隅、左クリックしてセル A6 にドラッグします (図 10)。
米。 10. リスト設定時の「作業コスト計算」シートの見方
「関数の選択」フィールドで「VLOOKUP」をクリックします（図11）。
米。 11. 関数ウィザードの最初のウィンドウの表示
「OK」ボタンをクリックします。
セルA3をクリックして、「検索値」フィールドに作品の名前を入力します。
「Enter」を押してください。
「テーブル」フィールドに情報を入力します。
「数式」メニューの「数式で使用」コマンドを使用し、「名前の挿入」を選択します。
「名前:」「価格リスト」を選択します (図 12)。
米。 12. 数式の引数として配列名を入力する
「OK」ボタンをクリックします。
「Enter」を押してください。
「Column_Number」フィールドに番号 2 の情報を入力します。
「Interval_viewing」フィールドに番号 0 の情報を入力します (図 13)。
米。 13. 関数ウィザードの 2 番目のウィンドウの表示
「OK」ボタンをクリックします。
14. 「実施した作業の範囲」の欄を記入します。
15. セル A4:A6 に作品名を入力します。
セル A4 をアクティブにします。
セル A4 の隣のボタンをクリックし、提案されたリストから作業の名前 - バッテリー交換、個を選択します。 セル C4 - 「生産単位あたりの価格、こすります。」 自動的に入力されます (図 14)。
米。 14. 自動充填商品名別商品単価
同様にセル A5:A6 に入力すると、セル C5:C6 も自動的に入力されます。
16.「作業費、ルーブル」欄に記入します。
表「実行された作業コストの計算」
このために：
セル D3 に数式 =B3*C3 を入力します。
セル D3 に入力された数式を、この列の残りのセル D4:D6 に乗算します (オートコンプリート機能を使用)。
したがって、制御パラメータが行番号であるループが実行されます。
17. 完成したテーブルは次のようになります (図 15)。
米。 15.「作業費の計算」表への記入結果
18. 「シート 3」の名前を「」に変更します。チェック "(段落 2 の手順と同様)。
19. 「アカウント」ワークシートで、前の段落に従って必要なテーブルを作成します。
20. LOOKUP() 関数を使用して、テーブル間のリレーションシップを作成します。 ただし、これを行う前に、「実行された作業コストの計算」テーブルの値を「作業名」列で昇順に並べ替えます。 このために：
セル範囲 A2:D6 を選択します。
ホームページで「並べ替えとフィルター」を選択し、次に「カスタム並べ替え」を選択します。
表示されるウィンドウで「並べ替え」「作品名」を選択します。
「OK」をクリックします。
「数式」メニューの「関数の挿入」コマンドを使用します。
「機能の選択」フィールドで「表示」をクリックします。
「OK」ボタンをクリックします。
セル C9 をクリックして、「検索値」フィールドに作品の名前を入力します。
「Enter」を押してください。
「表示するベクトル」フィールドに情報、つまり「作業コスト計算」を入力します!$A$3:$A$6;
「Enter」を押してください。
「必要なベクトル」フィールドに情報、つまり「作業コストの計算」を入力します!$С$3:$С$6;
「Enter」を押します（図16）。
米。 16. VIEW 機能ウィザードの 2 番目のウィンドウの表示
「OK」ボタンをクリックします。
22. セル D9:D12、E9:E12 に対してステップ 22 と同様のステップを繰り返します。
23. 表の「合計」列に次のように入力します。
セル F13 に数式 =SUM(F9:F12) を入力します。.
24.「VAT」欄に記入します。 これを行うには、セル F14 に数式 =F13*0.18 を入力します。
25. 「付加価値税を含む金額」欄に記入します。 これを行うには、セル F15 に数式 =F13+F14 を入力します。.
26. その結果、図 2 に示すテーブルが得られるはずです。 17.
米。 17. 実施した作業に対する支払いの請求書の形式
27. 受け取った注文の各タイプの作業のコストに関する情報を分析するには、次の手順を実行します。
「アカウント」シートをアクティブにします。
範囲 C9:F12 を選択します。
「挿入」メニューの「グラフ」セクションで「ヒストグラム」コマンドを選択します。
必要なヒストグラムのタイプを選択します。
ヒストグラムの名前を「各種類の作業のコスト」に変更します (図 18)。
米。 18. ヒストグラム 「各作業の費用」
2.3. コンピュータ実験の結果とその分析
2.3.1. コンピューター実験の結果
問題解決の正しさをテストするには、入力ドキュメントに記入し、結果を計算します。
|
価格表 |
|
|
役職 |
生産単位あたりの価格、こすれ。 |
|
浴槽の交換、部品。 |
|
|
パイプの交換、m |
|
|
壁紙ステッカー、m2 |
|
|
寄木細工の床、m2 |
|
|
天井の白塗り、m2 |
|
|
実行された作業のコストの計算 |
|||
|
役職 |
実施する業務範囲 |
生産単位あたりの価格、こすれ。 |
作業費、こする。 |
|
電池交換、個数。 |
1000 |
||
|
パイプの交換、m |
|||
|
壁紙ステッカー、m2 |
1400 |
||
|
寄木細工の床、m2 |
1200 |
||
|
ストロイデザイン合同会社 |
||||||||
|
アカウントなし。 |
||||||||
|
日付 |
|
|||||||
|
クライアントのフルネーム |
||||||||
|
いいえ。 |
役職 |
実施する業務範囲 |
生産単位あたりの価格、こすれ。 |
作業費、こする。 |
||||
|
電池交換、個数。 |
1000 |
|||||||
|
壁紙ステッカー、m2 |
1400 |
|||||||
|
パイプの交換、m |
||||||||
|
寄木細工の床、m2 |
1200 |
|||||||
|
合計： |
4560 |
|||||||
|
バット： |
820,8 |
|||||||
|
付加価値税を含む価格: |
5380,8 |
|||||||
問題を解いた結果、コンピュータを使用して得られたステートメントはテストされたステートメントと一致します。
2.3.2. 得られた結果の分析
したがって、結果として得られる文書（テーブル）「請求書」を作成することで、問題を解決できます。作業コストの計算時間を短縮し、人的要因によって引き起こされるエラーを排除し、顧客満足度を向上させることができます。 MS Excelを使用して表データに基づいてさまざまなチャート（ヒストグラム、グラフ）を作成すると、意思決定を行うための分析のための情報処理の結果を視覚的に表示するだけでなく、その構築領域での操作を迅速に実行することもできます。指定されたユーザー (アナリスト) パラメーターに従って視覚化結果を最も便利に表示することを優先します。
現代の基本的な考え方 情報技術変化を適切に反映するにはデータをデータベースに編成する必要があるという概念に基づいています。 現実の世界ユーザーの情報ニーズに応えます。 これらのデータベースは、データベース管理システム (DBMS) と呼ばれる特別なソフトウェア システムの制御下で作成され、動作します。
保存されるデータの量と構造の複雑さの増加、および情報システムのユーザーの輪の拡大により、最も便利で比較的理解しやすいリレーショナル (表形式) DBMS が広く使用されるようになりました。 多くのユーザーがデータに同時にアクセスできるようにするため、多くの場合、お互いに遠く離れていて、データベースが保存されている場所から離れた場所にいても、リレーショナル構造に基づいたネットワーク マルチユーザー バージョンのデータベースが作成されています。 これらは、何らかの形で、並列プロセス、データの整合性 (正確性) とセキュリティ、およびアクセス承認といった特定の問題を解決します。
DBMS は、メモリ内でのデータの物理的な配置とその説明について、事実上全く理解していない、または知りたくないユーザーも含め、あらゆるユーザーにデータへのアクセスを提供する必要があります。 要求されたデータを検索するためのメカニズム。 多くのユーザー (アプリケーション プログラム) が同時に同じデータを要求した場合に発生する問題。 不正な更新や不正アクセスからデータを確実に保護する方法。 データベースを最新の状態に保つなど、多くの DBMS 機能を備えています。
現在でも、リレーショナル データベースは、作成プロセスとユーザー レベルの両方でのそのシンプルさと明確さにより、依然として最も一般的です。
リレーショナル データベースの主な利点は、最も一般的な言語との互換性であることです。 SQLクエリ。 この言語の単一のクエリを使用すると、複数のテーブルを一時テーブルに結合し、そこから必要な行と列を切り出すことができます (選択と射影)。 リレーショナル データベースの表構造はユーザーにとって直感的であるため、SQL 言語はシンプルで習得が簡単です。 リレーショナル モデルには、リレーショナル データベースの進化と実装の基礎となる強固な理論的基盤があります。 リレーショナル モデルの成功によって生み出された人気の波に乗り、SQL はリレーショナル データベースの主要言語になりました。
上記の情報を分析する過程で、検討したデータベース モデルの次の欠点が特定されました。1 つのテーブルのすべてのフィールドには、事前定義されたタイプの一定数のフィールドが含まれている必要があるため、個々のフィールドを考慮して追加のテーブルを作成する必要があります。外部キーを使用した要素の特性。 このアプローチにより、データベース内に複雑な関係を作成することが非常に困難になります。 情報の操作と接続の変更は非常に複雑です。
実践的な部分では、MS Excel 2010 を使用して、改修工事の実施に関連する活動を行う架空の企業、Stroy-design LLC という会社に関連してタスクを解決しました。 表は課題で与えられたデータに基づいて作成されました。 受け取った注文の作業コストが計算され、計算データがテーブルに入力されます。 VLOOKUP または VIEW 関数を使用してテーブル間の接続が整理され、実行された作業の支払いのためにクライアントに発行される請求書が自動的に生成されます。 「実行された作業に対する支払いの請求書」という文書が生成され、記入されています。 受注した作業の種類ごとの原価計算結果をグラフで表示します。
情報学分野におけるコンピュータ トレーニング プログラム」/ A.N. ロマノフ、VS. トロプツォフ、D.B. グリゴロヴィッチ、LA ガルキナ、A.Yu。 アルテミエフ、NI ロボバ、K.E. ミハイロフ、ジョージア ジューコフ、O.E. クリチェフスカヤ、S.V. ヤセノフスキー、LA ヴドヴェンコ、ベルギー オジンツォフ、ジョージア州 ティトレンコ、GD サヴィチェフ、V.I. グセフ、SE スミルノフ、V.I. スヴォロバ、G.V. フェドロワ、GB コンヤシナ。 – M.: VZFEI、2000。日付更新日 2010 年 11 月 24 日。 – ログインとパスワードによるアクセス。
「経済学における情報システム」分野のコンピュータトレーニングプログラム / A.N. ロマノフ、VS. トロプツォフ、D.B. グリゴロヴィッチ、LA ガルキナ、A.V. モルトヴィチェフ、B.E. オジンツォフ、ジョージア州 ティトレンコ、LA ヴドヴェンコ、V.V. ブラガ、GD サヴィチェフ、V.I. スボーロフ。 – M.: VZFEI、2005 年。日付更新日 2010 年 10 月 15 日。 – URL: 。 ログインとパスワードでアクセスします。
データベース(DB) は、物理システムまたは仮想システムの特性を記述する、構造化され組織化されたデータのセットです。
データベース情報を保存するために設計された組織的な構造です。
DBMS- データベースのメンテナンスを組織するために設計されたツール ソフトウェア。
データベース モデルのタイプに基づいて、次のように分類されます。
階層型データベース
階層 DBMS は、非常に単純なデータ モデルに基づいており、特殊なタイプの非巡回有向グラフのツリーとして想像できます。 ツリーは頂点で構成されており、1 つを除く各頂点には 1 つの親頂点と複数の (なしを含む) 子があります。
ネットワークDBMS
階層モデルと同様に、ネットワーク モデルも有向グラフとして考えることができます。 ただし、この場合、グラフにはサイクルが含まれる可能性があります。 頂点は複数の親を持つことができます。
リレーショナル DBMS
リレーショナル DBMS は、 現在最も一般的な。 リレーショナル モデルは、2 次元テーブルの形式でデータを編成することに重点を置いています。 リレーショナル テーブルは 2 次元配列であり、次のプロパティがあります。
各テーブル要素は 1 つのデータ要素です。
テーブル内のすべての列は同種です。つまり、 列内のすべての要素は同じタイプ (数値、文字など) と長さを持ちます。
各列には一意の名前が付いています。
リレーショナル DBMS の成功には、リレーショナル データベースへのクエリ専用に開発された SQL 言語 (構造化クエリ言語) も重要な役割を果たしています。 これは非常にシンプルであると同時に表現力豊かな言語であり、これを使用すると、データベースに対して非常に高度なクエリを実行できます。
オブジェクト指向
外部イベントによって制御されるアプリケーション プログラムを含むオブジェクト モデルとしてデータがフォーマットされているデータベース。 最も一般的で古典的な設定では、オブジェクト指向アプローチは次の概念に基づいています。オブジェクトとオブジェクト識別子。 属性とメソッド。 クラス; 階層とクラスの継承。
多次元
OLAP ソフトウェアは、さまざまなソースからのデータの処理に使用されます。 これらのソフトウェア製品は、さまざまなデータ表現の実装を可能にし、次の 3 つの主な機能によって特徴付けられます。 データの複雑な計算。 時間の経過に伴うデータの変化に関連する計算。
9. プログラミング言語。 マシンコード。 翻訳者。 情報のバイナリコーディング。
プログラミング言語- 実行者 (コンピュータなど) にとって便利な形式でアルゴリズムを記述するように設計された正式な記号システム。 プログラミング言語は、コンピューター プログラムを構成するために使用される一連の語彙、構文、および意味の規則を定義します。 これにより、プログラマは、コンピュータがどのようなイベントに反応するか、データがどのように保存および送信されるか、さまざまな状況下でこのデータに対してどのようなアクションを実行する必要があるかを正確に決定できます。
プロセッサーのマシンコード
コンピュータのプロセッサは、すべてのコマンドとデータを電気信号の形式で受け取ります。 これらは、0 と 1 の集合、つまり数値として表すことができます。 チームが違えば番号も異なります。 したがって、実際には、プロセッサが動作するプログラムは、と呼ばれる一連の数値です。 マシンコード .
プログラミング言語のレベル
プログラミング言語が特定の種類のプロセッサに焦点を当て、その機能を考慮に入れている場合、その言語は次のように呼ばれます。 低レベルのプログラミング言語 . これは、言語演算子がマシンコードに近く、特定のプロセッサ コマンドに焦点を当てていることを意味します。
最低レベルの言語は アセンブリ言語 , これは、数値としてではなく、と呼ばれる記号表記を使用して、各機械語コードの命令を単純に表します。 記憶術。
高級プログラミング言語 コンピュータよりも人間にはるかに近く、理解しやすいものです。 特定のコンピュータ アーキテクチャの機能は考慮されていないため、ソース テキスト レベルで作成されたプログラムは、この言語のトランスレータが作成された他のプラットフォームに簡単に移植できます。
現在人気のあるプログラミング言語は次のとおりです。
パスカル（パスカル）、は、多くの現代プログラミングのアイデアの創始者である Niklaus Wirth によって 70 年代後半に作成され、大規模なプロジェクトを作成する際にうまく使用できる機能を備えています。
基本(ベーシック)、dこの言語にはコンパイラとインタプリタがあり、その人気は世界第 1 位です。 60年代に作られたものとして、 教育言語そしてとても学びやすいです。 その現代的な改良 ビジュアルベーシックは、Microsoft Office と互換性があり、Excel および Access パッケージの機能を拡張できます。
C(ケイ素)、この言語はベル研究所で作成されたもので、当初は大衆言語とは考えられていませんでした。 同様に効率的でコンパクトなプログラムを作成できると同時に、特定の種類のプロセッサに依存しないようにするために、アセンブラ言語を置き換えることが計画されました。 70 年代には、多くのアプリケーションおよびシステム プログラム、および多くのよく知られたオペレーティング システム (Unix) がこの言語で書かれていました。
Java や C# などの一部の言語は、コンパイル済み言語とインタプリタ言語の間に分類されます。 つまり、プログラムは機械語にコンパイルされるのではなく、低レベルの機械に依存しないコード、つまりバイトコードにコンパイルされます。 その後、バイトコードは仮想マシンによって実行されます。 通常、解釈はバイトコードの実行に使用されますが、プログラムの実行中にジャストインタイム コンパイル (JIT) を使用してバイトコードの個々の部分をマシン コードに直接変換してプログラムを高速化することもできます。 Java の場合、バイトコードは Java 仮想マシン (Java 仮想マシン、JVM)、C# - 共通言語ランタイム用。
論理データ モデル。リレーショナル データベースの構造、整合性、および処理の側面を説明する厳密な数学理論。
- 構造的側面 (コンポーネント) - データベース内のデータは一連の関係です。
- 整合性の側面 (コンポーネント) - 関係 (テーブル) は特定の整合性条件を満たします。 RMD は、ドメイン (データ型) レベル、関係レベル、およびデータベース レベルで宣言的整合性制約をサポートします。
- 処理 (操作) の側面 (コンポーネント) - RMD は関係操作演算子 (関係代数、関係微積分) をサポートします。
さらに、正規化理論は通常、リレーショナル データ モデルの一部として含まれます。
リレーショナル データ モデルは、集合論や形式論理などの数学分野のデータ処理問題への応用です。
「関係的」という用語は、理論が数学的な関係の概念に基づいていることを意味します。 テーブルという言葉は、「関係」という言葉の非公式の同義語としてよく使用されます。 「テーブル」は緩やかで非公式な概念であり、多くの場合、抽象的な概念としての「関係」を意味するのではなく、紙や画面上での関係の視覚的表現を意味することを覚えておく必要があります。
RMD をより深く理解するには、次の 3 つの重要な状況に注意する必要があります。
- モデルは論理的です。つまり、 関係は物理的 (保存された) 構造ではなく論理的 (抽象的) 構造です。
- リレーショナルデータベースの場合は true 情報原理: データベースのすべての情報コンテンツは、唯一の方法、つまり関係タプルで属性値を明示的に指定することによって表現されます。 特に、ある値を別の値にリンクするポインタ (アドレス) はありません。
- 可用性 関係代数ナビゲーション (手続き型) プログラミングと手続き型条件チェックに加えて、宣言型プログラミングと整合性制約の宣言型記述を実装できます。
リレーショナル モデルの原則は、1969 年から 1970 年にかけて E. F. コッドによって定式化されました。 Codd のアイデアは、古典となった「大規模共有データ バンクのためのデータのリレーショナル モデル」という記事で最初に詳しく説明されました。
現代的な意味でのリレーショナル データベース (リレーショナル データ モデル) の理論の厳密な説明は、K. J. Data の著書にあります。 「C. J.Date. データベース システムの概要」 (「Date、K. J. データベース システムの概要」)。
リレーショナル モデルの代替となるのは、階層モデルと ネットワークモデル。 これらの古いアーキテクチャを使用する一部のシステムは、現在でも使用されています。 さらに言えば、 オブジェクトモデルいわゆるオブジェクト DBMS が構築されるデータですが、そのようなモデルには明確で一般的に受け入れられている定義はありません。
リレーショナル モデルの利点
- シンプルでエンドユーザーにとって理解しやすい - 唯一の情報構造はテーブルです。
- リレーショナル データベースを設計するときは、数学的装置に基づいた厳密なルールが適用されます。
- 完全なデータ独立性。 リレーショナル構造を変更する場合、アプリケーション プログラムに加える必要がある変更は最小限で済みます。
- クエリを構築してアプリケーション プログラムを作成するために、外部メモリ内のデータベースの特定の構成を知る必要はありません。
リレーショナル モデルの欠点
- アクセス速度が比較的遅く、外部メモリの容量が大きい。
- 論理設計により多数のテーブルが出現するため、データ構造の理解が困難。
- 主題領域を一連の表の形式で提示できるとは限りません。
ポストリレーショナル DBMS。 オブジェクト DBMS。 リレーショナル DBMS の欠点。 オブジェクト指向 DBMS の基本概念。
リレーショナル データベース管理システムには制限があります。 これらは、チケットやホテルの予約システムなどの従来のアプリケーションだけでなく、 銀行システムしかし、設計自動化システム、インテリジェント製造システム、その他の知識ベースのシステムにそれらを適用することは、多くの場合困難です。 これは主に、リレーショナル データ モデルの基礎となるデータ構造の原始性によるものです。 フラットな正規化された関係は普遍的であり、理論的にはあらゆる主題領域のデータを表すのに十分です。 ただし、非従来型アプリケーションでは、データベース内に数千ではないにしても数百のテーブルがあり、ドメイン固有の複雑なデータ構造を再構築するために必要な高価な結合操作が常に行われます。
リレーショナル システムのもう 1 つの重大な制限は、アプリケーション セマンティクスを表現する能力が比較的弱いことです ( セマンティクス- プログラミングにおける - 個々の言語構造を解釈するためのルールのシステム。 セマンティクスアルゴリズム言語における文の意味論的な意味を決定します...)。 リレーショナル DBMS が提供する機能のほとんどは、データ整合性制約を定式化してサポートする機能です。 データベース研究者は、リレーショナル システムのこれらの制限と欠点を認識し、リレーショナル データ モデルを超えたアイデアに基づいて数多くのプロジェクトを推進しています。
リレーショナル DBMS には他にも次のような欠点があります。
· データベース開発の構造の柔軟性のなさ、
構築の難しさ 概念モデル多数の多対多の関係を持つオブジェクトの場合、
· スパース データ配列の不自然なテーブル表現。
オブジェクト指向データベースは比較的新しいものであるため、データベース理論にはリレーショナル モデルやツリー モデルのような優れた数学的基礎がありません。 ただし、これは必ずしもモデリング テクノロジーに固有の弱点の兆候であると見なすべきではありません。 ほとんどのデータベース実装に共通すると思われるプロパティは次のとおりです。
1. 抽象化:データベースに保存されている実際の「もの」はすべて、何らかのクラスのメンバーです。 クラスは、プロパティ、メソッド、パブリックおよびプライベートのデータ構造、およびそのクラスのオブジェクト (インスタンス) に適用されるプログラムのコレクションとして定義されます。 クラスは抽象データ型にすぎません。 メソッドは、オブジェクトに対して何らかのアクション (たとえば、それ自体を印刷したり、それ自体をコピーしたり) を実行するために呼び出されるプロシージャです。 プロパティは、各クラス オブジェクトに関連付けられたデータ値であり、何らかの方法でそれを特徴付けます (色、年齢など)。
2.カプセル化:データの内部表現とパブリックおよびプライベート メソッド (プログラム) の実装の詳細はクラス定義の一部であり、そのクラス内でのみ知られます。 クラスのオブジェクトへのアクセスは、そのクラスまたはその親のプロパティとメソッド (下記の「継承」を参照) を通じてのみ許可され、内部実装の詳細に関する知識を使用することによっては許可されません。
3. 継承 (単一または複数):クラスはクラス階層の一部として定義されます。 各下位レベルのクラス定義は、明示的に継承不可と宣言されているか、新しい定義によって変更されていない限り、その親のプロパティとメソッドを継承します。 単一継承では、クラスは親クラスを 1 つだけ持つことができます (つまり、クラス階層はツリー構造になります)。 多重継承では、クラスは複数の親から派生することができます (つまり、クラス階層は、必ずしもツリー構造ではなく、有向非循環グラフの構造を持ちます)。
4. ポリモーフィズム注: 複数のクラスは、異なるものとみなされている場合でも、同じメソッド名とプロパティ名を持つことができます。 これにより、対応するメソッドとプロパティがこれらのクラスで定義されている限り、完全に異なるクラスのオブジェクトに対して正しく動作するアクセス メソッドを作成できます。
5. メッセージ: オブジェクトとの対話は、応答を受信する可能性のあるメッセージを送信することによって実行されます。
各オブジェクト (その情報が OODB に格納されている) はクラスに属しているとみなされ、クラス間の接続はクラスのプロパティとメソッドを使用して確立されます。
OODB モデルは、リレーショナル データベースやツリー データベースよりも抽象化のレベルが高いため、これらのモデルのいずれか、またはその他のモデルに基づいてクラスを実装できます。 データ構造ではなく手順 (メソッド) が開発の中心となるため、十分な強度、柔軟性、および処理パフォーマンスを提供するベース モデルを選択することが重要です。
リレーショナル データベースは、構造が厳密に定義され、許可される操作が限られているため、OODB のベース プラットフォームとしては明らかに適していません。 さらなる機能を備えた M 言語システム 柔軟な構造データと、開発に対するより手順的なアプローチ。
DBMS は、ユーザーがデータベースを定義、作成、保守し、データベースへの制御されたアクセスを提供できるソフトウェアです。
オブジェクト リレーショナル DBMS には、Oracle Database や PostgreSQL などがあります。 オブジェクト リレーショナル DBMS とオブジェクト ベース DBMS の違い: 前者はリレーショナル スキーマの上位構造であるのに対し、後者は最初はオブジェクト指向です。
リレーショナル DBMS 内のオブジェクトへのアクセス。1) DBMS はページを定義します。 外部装置必要なレコードを含むストレージ。 インデックスメカニズムを使用するか、 全景テーブル。 次に、DBMS はこのページを外部記憶装置から読み取り、CACHE 2 にコピーします。DBMS は、データを CACHE からアプリケーションのメモリ空間に順次転送します。 SQL データ型からアプリケーション データ型への変換を実行する必要がある場合があります。 アプリケーションはメモリ空間内のフィールド値を更新できます。 3. SQL 言語を使用してアプリケーションによって変更されたデータ フィールドは、DBMS CACHE に転送されます。この際、再度データ型変換の実行が必要になる場合があります。 4. DBMS は更新されたページを CACHE から書き換えて外部記憶装置に保存します。
OODBMS 内のオブジェクトへのアクセス。 1. OODBMS の検索必要に応じてインデックスを使用して、必要なオブジェクトを含むページを外部記憶装置に印刷します。 次に、OODBMS は外部記憶装置から必要なページを読み取り、アプリケーションに割り当てられたメモリ内にあるアプリケーションのページ CACHE にコピーします。 2. OODBMSmは、いくつかの変換を実行できます。 1. あるオブジェクトの参照 (ポインタ) を別のオブジェクトに置き換えます。 2. プログラミング言語の要件に確実に準拠するために必要な情報をオブジェクト データに導入します。 3. 異なるハードウェア プラットフォームまたはプログラミング言語で作成されたデータを表示するための形式を変更する。 3. アプリケーションが実装するのは、オブジェクトにアクセスし、必要に応じて更新します。 4. アプリケーションが加えられた変更を永続的にする必要がある場合、またはページを CACHE からディスクに一時的にアンロードする必要がある場合、ページを外部ストレージ デバイスにコピーする前に、OODBMS は上記と同様の逆変換を実行する必要があります。
チケット番号 27
経済バランス、企業の事業活動。 企業の財務バランス。 レバレッジ効果。 負債レベルの分析。 生産活動におけるキャッシュフローの分析。
企業の事業活動通常、投資された（国内）資本の使用の激しさによって特徴付けられます。 生産では、資本が絶えず動いており、回路のある段階から別の段階に移動します。つまり、テクノロジー D®T®…®P®…T®D が実装されます。」
たとえば、第 1 段階では、企業は固定資産と在庫に投資します。第 2 段階では、在庫という形で資金が生産され、その一部が従業員への給与、税金、社会保障の支払いなどに使用されます。経費。 この段階は完成品のリリースで終了します。 第 3 段階では、完成品が販売され、企業が受け取ります。 現金。 資本の循環が速くなればなるほど、企業は同じ投下資本でより多くの製品を受け取り、販売できるようになります。 どの段階であっても資金移動の遅れは資本回転率の低下につながり、追加の資金投資が必要となり、資本の使用状況が大幅に悪化する可能性があります。
投下資本の効率性は以下の指標を算出して評価します。
リレーショナル データベースの論理モデルリレーショナル データベース オブジェクトに変換します。 この問題を解決するには、データベース設計者は次のことを知る必要があります。 a) リレーショナル データベースには原理的にどのようなオブジェクトがあるのか。 b) データベースを実装するために選択された特定の DBMS によってサポートされるオブジェクト。したがって、DBMS を選択する決定は、IT プロジェクト マネージャーによってすでに行われており、データベースの顧客と合意されていると仮定します。 DBMSを指定します。 データベース設計者は、選択した DBMS でサポートされる SQL 言語について説明したドキュメントを確認する必要があります。 この講義では、Oracle 9i DBMS が選択されたことを前提としていますが、内容の大部分は産業用リレーショナル DBMS のオブジェクトをカバーしています。
コメント。 DBMSの選択について。 DBMS の選択は複数の基準による選択の問題であり、このコースでは説明しません。 DBMS は通常、リレーショナル、階層、ネットワーク、多次元、オブジェクト指向、オブジェクト リレーショナルの 1 つのデータ モデルのみをサポートしていることに注意してください。 例外は、少数の DBMS です。 たとえば、ADABAS、Software AG (ネットワークおよびリレーショナル モデル)、Oracle 9i、Oracle Inc. (リレーショナル モデルおよびオブジェクト リレーショナル モデル)。 通常、DBMS を選択するときは、他の可能性がすべて同じであるとして、業界標準を主張する DBMS 上にデータベースを作成しようとします。
リレーショナル データベース オブジェクトの階層は SQL 標準、特に SQL-92 標準で規定されており、この講義で内容を説明する際にはこれに焦点を当てます。 この標準は、デスクトップ DBMS を含むほとんどすべての最新の DBMS でサポートされています。 リレーショナル データベース オブジェクトの階層を次の図に示します。
最下位レベルには、リレーショナル データベースが扱う最小のオブジェクト、つまり列 (列) と行があります。 これらは、テーブルとビューにグループ化されます。
コメント。 講義の文脈では、属性、列、列、およびフィールドは同義語とみなされます。 同じことが「文字列」、「レコード」、「タプル」という用語にも当てはまります。
データベースの論理構造の物理的表現を表すテーブルとビューは、スキーマに組み立てられます。 複数のスキーマはカタログに収集され、その後クラスターにグループ化できます。 SQL-92 標準のオブジェクト グループはいずれも、コンピュータ メモリ内に情報を物理的に保存するための構造に関連付けられていないことに注意してください。
米。 8.1.
図に示されているオブジェクトに加えて、インデックス、トリガー、イベント、ストアド コマンド、ストアド プロシージャ、およびその他の多数のオブジェクトをリレーショナル データベース内に作成できます。 次に、リレーショナル データベース オブジェクトの定義に進みましょう。
リレーショナル データベースの基本オブジェクト
クラスター、ディレクトリ、スキーマは標準の必須要素ではないため、 ソフトウェア環境リレーショナル データベース。
クラスタは、データベース サーバー (DBMS ソフトウェア コンポーネント) への単一の接続を通じてアクセスできるディレクトリのグループです。
実際の手順 ディレクトリを作成する特定の DBMS の実装によって決定されます。 オペレーティングプラットフォーム。 カタログはスキームのグループとして理解されます。 実際には、ディレクトリはコレクションとして物理データベースに関連付けられることがよくあります。 物理ファイルオペレーティング システムは名前によって識別されます。
データベース設計者にとって、スキーマは完全なデータベースの関係を全体的に論理的に表現したものです。 SQL 用語では、スキーマはテーブル、ビュー、およびリレーショナル データベースのその他の構造要素のコンテナーです。 各スキーマ内のデータベース要素の配置は、データベース設計者によって完全に決定されます。
テーブルとビューを作成するためにスキーマは必要ありません。 論理データベースを 1 つだけインストールする予定の場合は、スキーマなしでインストールできることは明らかです。 ただし、同じ DBMS を使用して複数のデータベースをサポートする予定がある場合は、データベース オブジェクトをスキーマに適切に編成すると、それらのデータベースの保守がはるかに簡単になります。 実際には、スキーマは物理データベース内の特定のユーザーのオブジェクトに関連付けられることがよくあります。
次に、リレーショナル データベース オブジェクトが Oracle 9i リレーショナル DBMS のコンテキストに入力されます。 このアプローチが採用されたのは、設計上の理由からです。 リレーショナル データベースの物理モデル特定の実装環境に対して実行されます。
Oracle 9i では、ユーザーが作成するすべてのデータベース オブジェクトを表すために「スキーマ」という用語が使用されます。 新しいスキーマは、新しいユーザーごとに自動的に作成されます。
リレーショナル データベースの主なオブジェクトには、テーブル、ビュー、ユーザーが含まれます。
テーブルはリレーショナル データベースの基本構造です。 これはデータストレージの単位、つまり関係を表します。 テーブルはデータベース内で一意の名前によって識別されます。この名前にはユーザーの ID が含まれます。 テーブルは空にすることも、行のセットで構成することもできます。
ビューは、1 つ以上のデータベース テーブルから選択された名前付きの動的に維持される DBMS です。 フェッチ オペレーターは、ユーザーに表示されるデータを制限します。 通常、DBMS はビューの関連性を保証し、ビューが使用されるたびに生成されます。 表現が呼ばれることもあります 仮想テーブル.
ユーザーは、他のデータベース オブジェクトを作成または使用し、セッションの編成やデータベースの状態の変更などの DBMS 機能の実行を要求できるオブジェクトです。
オブジェクトの識別と名前付けを容易にするために、データベースではシノニム、シーケンス、および などのオブジェクトがサポートされています。
同義語 ( シノニム）- これ 代替名このオブジェクトへのアクセスを可能にするリレーショナル データベースのオブジェクト (エイリアス)。 シノニムは一般またはプライベートにすることができます。 共有シノニムを使用すると、すべてのデータベース ユーザーが対応するオブジェクトをそのエイリアスで参照できるようになります。 シノニムを使用すると、データベース内のオブジェクトの完全な修飾情報をエンド ユーザーから隠すことができます。
Sequence は、マルチユーザーの非同期アクセスで一意の番号 (数字) のシーケンスを生成できるようにするデータベース オブジェクトです。 通常、シーケンス要素は、データ変更操作でテーブル要素 (行) に一意の番号を付けるために使用されます。
ユーザー定義のデータ型 (ユーザー定義のデータ型)は、DBMS がサポートする (組み込み) タイプとは異なるユーザー定義の属性タイプ (ドメイン) です。 これらは組み込み型に基づいて定義されます。 ユーザー定義のデータ型オブジェクト指向パラダイムに従って編成された DBMS 環境の一部を形成します。
データへの効率的なアクセスを確保するために、リレーショナル DBMS は、インデックス、テーブル領域、クラスター、セクションなど、他の多くのオブジェクトをサポートします。
インデックスは、データ取得パフォーマンスを向上させ、主キー (テーブルに指定されている場合) の一意性を制御するために作成されるデータベース オブジェクトです。 完全に索引付けされた表 (索引構成表) は、表と索引の両方として同時に機能します。
テーブルスペースまたはエリア ( テーブルスペース)テーブルとインデックスにメモリを割り当てるために使用されるデータベースの名前付き部分です。 Oracle 9i では、これはオペレーティング システムの物理ファイルの論理名です。 データを保存するすべてのデータベース オブジェクトは、次のいずれかに対応します。 テーブルスペース。 データを保存しないほとんどのデータベース オブジェクトは、SYSTEM テーブルスペースにあるデータ ディクショナリに存在します。
クラスターは、複数または 1 つのテーブルにデータをまとめて保存する方法を定義するオブジェクトです。 クラスターを使用する基準の 1 つは、複数のテーブルに同じ SQL コマンドで使用される共通のキー フィールドがあることです。 通常、クラスター化された列またはテーブルは、次のようにデータベースに保存されます。 ハッシュテーブル（つまり、特別な方法で）。
パーティションは、データを含むオブジェクトを、さまざまな領域に割り当てられたサブオブジェクトのコレクションとして表すことができるデータベース オブジェクトです。 テーブルスペース。 したがって、 セクショニング非常に配布できます 大きなテーブル複数のハードドライブ上にあります。
データを特別な方法で処理したり、実装したりするため 参照整合性のサポートデータベース オブジェクトが使用されます: ストアド プロシージャ、関数、コマンド、トリガー、タイマー、パッケージ (Oracle)。 これらのデータベース オブジェクトを使用すると、いわゆるデータのレコード処理を実行できます。 データベース アプリケーションの観点から見ると、行処理とは、一度に 1 行ずつデータを順次選択して処理し、次の行の処理に進むことです。
これらのリレーショナル データベース オブジェクトはプログラムです。 実行可能コード。 このコードは、リレーショナル データベース エンジンがインストールされているコンピューターによって実行されるため、通常、サーバー側コードと呼ばれます。 このようなコードの計画と開発は、リレーショナル データベース設計者のタスクの 1 つです。
ストアド プロシージャは、特殊なデータベース プログラミング言語 (SQLWindows や PL/SQL など) の SQL コマンドやステートメントの名前付きセットを表すデータベース オブジェクトです。
Function は、SQL コマンドや特殊なデータベース プログラミング言語演算子の名前付きセットを表すデータベース オブジェクトで、実行すると値 (計算結果) を返します。
コマンドは、プリコンパイルされてデータベースに保存される名前付き SQL ステートメントです。 対応するコマンドよりもコマンド処理速度が高速です。 SQL文、 なぜなら フェーズは実行されません 解析するそしてコンピレーション。
トリガーは、特別なストアド プロシージャであるデータベース オブジェクトです。 このプロシージャは、トリガー イベントが発生すると (たとえば、テーブルに行が挿入される前に) 自動的に実行されます。
タイマーは、ストアド プロシージャのトリガー イベントがタイマー イベントであるという点でトリガーとは異なります。
パッケージは、名前付きの構造化された変数、プロシージャ、関数のセットで構成されるデータベース オブジェクトです。
分散リレーショナル DBMS には、スナップショットとデータベース リンクという特別なオブジェクトがあります。
スナップショット (スナップショップ) は、テーブルまたはクエリ結果を複製 (複製) するために使用される、リモート データベース内のテーブルのローカル コピーです。 スナップショットは変更可能または読み取り専用の場合があります。
データベース リンク (リモート データベース リンク) は、リモート データベース内のオブジェクトにアクセスできるようにするデータベース オブジェクトです。 データベース リンク名は、大まかに言えば、リモート データベースのパラメータにアクセスするためのリンクと考えることができます。
データ・アクセス制御を効果的に管理するために、Oracle はロール・オブジェクトをサポートしています。
ロールは、ユーザー、ユーザーのカテゴリ、またはその他のロールに割り当てることができる名前付き権限セットであるデータベース オブジェクトです。