中国電子科学技術大学データベースとソフトウェア工学実験4（コースデザイン）

1960 年代以前は、コンピュータが実用化されたばかりで、ソフトウェアの設計は、コンピュータに依存した機械語やアセンブリ言語を使用して、特定の用途に合わせて指定されたコンピュータ上で設計、コンパイルされることが多く、ソフトウェアの規模は比較的小規模でした。データは通常存在せず、体系的な開発手法はほとんど使用されないソフトウェアの設計はプログラミングと同等であることが多い基本的には個人設計、個人使用、個人運用、自己完結型の私的なソフトウェア制作手法である。

1960年代半ば、大容量かつ高速なコンピュータの登場により、コンピュータの応用範囲は急速に拡大し、ソフトウェア開発も急増しました。高級言語が登場し始め、オペレーティングシステムの発展によりコンピュータの応用方法が変化し、大量のデータ処理により第一世代のデータベース管理システムが誕生しました。ソフトウェアシステムの規模はますます大きくなり、複雑性はますます高まり、ソフトウェアの信頼性の問題はますます顕著になってきています。本来の個人的なデザインや個人使用の方法ではもはや要件を満たせなくなり、ソフトウェアの生産方法を変え、ソフトウェアの生産性を向上させることが急務となっており、ソフトウェア危機が勃発し始めています。

1.1.2 ソフトウェアエンジニアリングの概念の提案

1968 年、北大西洋条約機構 (NATO) はドイツ連邦共和国での国際学術会議でソフトウェア危機という用語を作りました。 1960 年代半ばに有名なソフトウェア危機が勃発し始めましたが、この問題を解決するために 1968 年と 1969 年に 2 つの有名な NATO 会議が開催され、同時にソフトウェアエンジニアリングの概念が提案されました。

ソフトウェア開発で遭遇する問題には解決策がなく、問題が積み重なり鋭い矛盾が形成され、ソフトウェア危機につながります。なぜなら、当時の単一プログラム開発技術は、もはや大規模で複雑なソフトウェアシステムには適用できなくなったからです。その結果、消費時間が長くなり、コストが高く見積もられ、信頼性が低くなり、メンテナンスが困難になります。疑わしい問題をより効果的に解決するために、ソフトウェアエンジニアリングという学問が生まれました。

1.2 ソフトウェアエンジニアリングの定義

Computer Encyclopedia によるソフトウェアエンジニアリングの定義:

コンピューターサイエンス、数学、管理科学の原理を応用して、エンジニアリング手法を使用してソフトウェアを作成します。従来のエンジニアリング原理と手法を利用してソフトウェアを作成し、品質を向上させ、コストを削減します。

その中で、コンピューターサイエンスと数学はモデルとアルゴリズムの構築に使用され、工学科学は仕様の指定、パラダイムの設計、コストの評価とトレードオフの決定に使用され、管理科学は計画、リソース、品質、コストなどの管理に使用されます。。

ソフトウェアエンジニアリングは、コンピュータソフトウェアの開発とメンテナンスを指導する工学分野です。ソフトウェアエンジニアリングは学際的な分野です。

最初の NATO 会議におけるソフトウェアエンジニアリングの定義:

ソフトウェアエンジニアリングは、信頼性が高く、実際のマシン上で効率的に動作するソフトウェアを経済的に取得するために、健全なエンジニアリング原則を確立および使用する実践です。

IEEE によるソフトウェアエンジニアリングの定義:

(1) ソフトウェアの開発、運用、保守に体系的、標準化され、定量化可能な方法を適用する。つまり、ソフトウェアにエンジニアリング手法を適用する。

(2) (1)の方法に関する研究。

1.3 階層型ソフトウェアエンジニアリング

ソフトウェアエンジニアリングは階層的なテクノロジーであり、次の 4 つのレベルに分類できます。

ツール層: ソフトウェア開発プロセスでは、モデリングツール Rational Rose などのツールが自動または半自動のサポートを提供します。

メソッド層: メソッドは、要件分析、プログラミング、テストなど、ソフトウェア開発に技術的に必要な一連のタスクを提供します。

プロセス層: プロセスは、ソフトウェアを合理的かつタイムリーに開発できるようにする開発フレームワークを提供します。

品質保証層: 計画的かつ体系的なアプローチを確立し、提案された標準、手順、慣行、方法がすべてのプロジェクトに正しく採用されていることを管理者が保証します。ソフトウェア品質保証の目的は、ソフトウェアプロセスを管理者が見えるようにすることです。ソフトウェア製品と活動のレビューと監査を通じて、ソフトウェアが標準に準拠していることを検証します。

図 1-1 ソフトウェアエンジニアリングの階層図

さらに、ソフトウェアエンジニアリングは、数学、エンジニアリング、コンピューターサイエンス、心理学、経営学、経済学の知識を含む学際的な分野であり、体系的で標準化された階層的なプロジェクトです。

1.4 ソフトウェアエンジニアリングマネジメントの意義

1) ソフトウェア開発プロジェクト中にプロジェクト管理がなくてもソフトウェアプロジェクトは成功しますが、ソフトウェア開発の本来の目的は利益を上げることであり、プロジェクト管理はまさに利益の保証です。ソフトウェア開発プロセスを作成する仕事をするとき、優れたプロジェクトマネージャーはプロジェクトで非常に重要な役割を果たします。ソフトウェア開発作業では、プロジェクト管理の実装はソフトウェアプロジェクトの収益源の多くの要件を満たすことができますが、基本的には各プロジェクトとあらゆる側面の利害関係者が互いに協力し、関連リソースをソフトウェア開発プロジェクトに統合して、期待される目標を達成します。
2) 現在、わが国の多くのソフトウェア開発会社が開発を行っているとき、製品ベースのソフトウェアであっても、プロジェクトベースのソフトウェアであっても、これらのソフトウェア開発会社はソフトウェア開発に対して非常に厳格です。企業の実情に合った経営モデルが存在しない。個別のソフトウェア開発会社の中には、関連する理論に基づいて適切な管理計画を策定しているところもありますが、それでもソフトウェア開発で直面する時間、利益、品質管理などの問題を根本的に解決することはできません。そのため、労働時間の延長、リスクの発生確率の不安定、ソフトウェア製品の品質の制御不能などの問題が発生し、特にソフトウェア開発の最終段階では、メンテナンス困難やアップグレード困難などの問題が頻繁に発生し、企業の経営を脅かすことになります。ソフトウェアユーザーの利益は、ソフトウェア開発会社の利益も損なうことになります。上記によれば、ソフトウェア開発業務を遂行する際に、効果的なプロジェクト管理を実施することは、ソフトウェア開発の成功率を保証するだけでなく、企業の利益を最大化することもできる。

1.5 ソフトウェアエンジニアリング管理の現状

1) 今日の情報技術レベルの継続的な向上に伴い、ソフトウェア開発と生産作業の規模はますます大きくなり、同時にソフトウェア開発のあらゆる側面がより複雑になっています。一部の小規模または小規模なワークショップスタイルのソフトウェア開発モデルは、今日の社会の急速な発展のニーズに適応できなくなりつつあります。現段階では、多くのソフトウェア会社がプロジェクト管理モデルを自社の開発に積極的かつ熱心に統合しています。ソフトウェア開発作業を合理的、科学的、効果的に管理するソフトウェアプロジェクト管理作業の実施により、利益、人員、効率、品質、リスクなどの要素に関する管理要件が満たされ、ソフトウェア開発作業が可能になります。予想される利益、効率、品質の要件に合わせて改良する必要があります。
2) ソフトウェア開発業務を遂行する場合、各プロジェクトの責任者は、定められた期間内に担当分野の業務を完了し、標準化された合理的かつ科学的な管理を行わなければなりません。プロジェクト管理は、企業が関連する技術担当者の要件を減らすだけでなく、ソフトウェア製品開発に必要な資本投資を根本的に削減するのに役立ちます。ソフトウェア開発作業にプロジェクト管理を導入することは、企業にとって次のような利点があるだけではありません。同時に、一部のソフトウェア開発者が個人のビジネス能力をさらに向上させるのにも役立ちます。
3) 現在、ソフトウェア開発作業は多様化、複雑化しています。特に、多くの開発チームが定期的にソフトウェア開発作業を行っている場合、同時に異なるバージョンが存在することもあります。 , 複数拠点での同時研究開発や開発と保護の共存といった問題の顕在化により、ソフトウェアの開発や管理に重大な困難と影響が生じています。これが厳格に管理されていないか、管理が少しでも不注意であると、バージョンの混乱やスタッフ間の干渉など、ソフトウェア開発作業に支障をきたす問題が次々と発生します。

1.5 ソフトウェアエンジニアリング管理の重要性

コンピュータソフトウェアの開発プロセスにおいて、プロジェクト管理とは、主にプロジェクトのコスト、品質、リスク、スケジュール等を管理し、期待通りに完了できるかどうか、さまざまな外部干渉要因を排除できるか、人材の資質などの合理的な管理を行うことをいいます。ただし、プロジェクト管理プロセスに影響を与える要因には、製品の作業負荷、アプリケーションのリソース、構成などが含まれます。複数の関係者とプロジェクト管理。近年、ネットワーク技術の発展に伴い、コンピュータがさまざまな分野で利用されるようになり、ソフトウェア開発の観点から見ると、コンピュータが占める割合はますます高まっています。ソフトウェア開発はプロセスが比較的複雑で複数の立場の協力が必要であり、また、ソフトウェア開発は複雑かつ大規模なプロジェクトであり、より大きなリスクに直面するため、その後の管理プロセスも難しくなり、開発期間中も非常に困難です。ソフトウェア開発ではさまざまな問題が発生しやすく、プログラム管理者が異なっても問題の発生を完全に回避することはできないため、ソフトウェア開発中に遭遇するさまざまな問題を解決するには有効な対策を立てる必要があります。

1.6 ソフトウェアエンジニアリングの目標

ソフトウェアエンジニアリングの目標は、開発コストを削減し、必要なソフトウェア機能を実現し、一定のコストと時間の要件内でソフトウェアのパフォーマンスを向上させることです。; 開発されたソフトウェアは、移植が可能で、メンテナンスコストが低く、開発作業を予定通りに完了し、タイムリーに使用できるように納品できます。

ソフトウェア設計では、通常、モジュール性、抽象化と情報隠蔽、ローカリゼーション、一貫性、適応性などのソフトウェアの特性を考慮する必要があります。適切な設計方法を使用すると、これらの特性の実装が容易になり、ソフトウェアエンジニアリングの目標を達成できます。

第 2 章要件分析

2.1アプリケーションとユーザーニーズの分析

2.1.1 アプリケーション環境の分析

このデータベースは主に学生の基本的な情報管理システムのニーズを満たすために使用されます。学生の基本情報の管理には、学生の基本情報、学生の学校情報、学生情報、職業情報、宿泊情報などが含まれます。学生の基本情報から多くの基本的なエンティティを分解できます。

学校には複数のキャンパスがあり、各キャンパスに寮棟が存在しますが、当然のことながら、全キャンパスの寮棟は統一化されており、つまり全キャンパスの寮棟の棟番号が統一されています。

専攻情報は学生の専攻のみを記録する必要があり、学生は 2 つ以上の専攻を学ぶことができますが、学生の専攻のみが記録されます。専攻は 1 つの大学にのみ属します。

上記の基本情報からわかるように、主に学生情報管理、物流情報管理、専門情報管理に分類されます。

2.1.2 アプリケーションの特性

このデータベースアプリケーションは、主に大学における学生情報管理を目的としており、一般的には学生、教務担当者、カウンセラー、物流管理者などが主なシナリオとなります。

システムに保存されているコンテンツは 1 年以内にほとんど変化しないため、情報を調整する必要があるのは少数の学生のみです。ただし、年齢を変更した場合には大規模な情報調整が必要となる場合があるため、バッチ運用に合わせた設計が必要です。次に、システムへの情報入力は主に入学時や諸手続きの際に行われますが、次の学年以降は定期的に権限を開放して学生自身の情報を管理できるようにする場合があります。キャンパスの変更や専攻の調整などのニーズがまだある学生もいる。ほとんどの場合、さまざまなユーザーのクエリのニーズに対応します。要約すると、システムには追加、削除、確認、変更などの基本的な操作が必要ですが、後でいくつかの複雑な操作を設計することもできます。

2.1.3 ユーザーのニーズ

主な利用者としては、学生、物流担当者、教務担当者、大学教務担当者が挙げられます。

学生のニーズ: 自分の情報を表示し、許可があれば情報を変更できます。

物流管理者のニーズ：物流管理者は主に、グループ番号、部屋の名前、新入生の部屋の割り当てなど、学校全体の寮情報を管理します。 Communicationでは寮番号などの情報も利用して、学生の情報をすぐに見つけることができます。

教務室長：全学部の情報管理、全学キャンパス間の人員管理・配置などを担当。同時に、学生情報をすばやく変更および照会することができます。

学部教務室長：学内の情報管理と学生の専攻区分を担当するとともに、学生の情報を迅速に照会・変更することができます。

2.2 機能分析

機能分析は主に、学生の基本情報データベースを構築するためのシステム設計分析と、学生に起こり得るデータフローの運用分析です。この学生基本情報管理システムのニーズに応じて、専攻変更や学部変更、アップグレードによるキャンパス変更、アップグレードによる寮変更、留年・退学等が発生する場合があります。その他の要因等により、

2.2.1 学生が専攻を変更する

図 2-1 学生の専攻変更のデータの流れ

専攻変更により所属学部が変更になる場合がありますが、主キー学籍番号は変更されません。

2.2.2 アップグレードによる学生のキャンパス変更

図 2-2 アップグレードによる学生のキャンパスや寮の変更

学生はそれぞれの大学のキャンパス内に配置されており、状況に応じて調整される場合があります。例えば、とある学校

コンピュータサイエンス学部は、1 年目はキャンパス 1 にありますが、2 年目にはキャンパス 3 に調整される場合があります。同時に、学生の寮変更や新寮へのチェックイン手続きも行われ、学生寮の建物区分も変更となります。

2.2.3 退学による学生情報の変更

図2-3 退学による学生情報の変更

退学等により退学した場合、入学時に登録した情報は削除されます。

2.3 データ要件の具体的な説明

2.3.1 主なデータ構造の説明

要件分析では、データ構造が要件に対応するエンティティを分析する必要があります。

(1)学生

	データ構造：	学生
	意味：	学生基本情報管理システムの主要なデータ構造であり、学生の関連情報を定義します。
	構成：	学生番号、氏名、性別、生年月日、民族、ID番号、所属政党、携帯電話番号、連絡後、寮番号、専攻番号、大学番号等が記載される場合があります。

(2) プロフェッショナル

	データ構造：	選考科目
	意味：	学生基本情報管理システムの基本的なデータ構造であり、学生と大学との関係を定義します。
	構成：	専攻コード、専攻名、主な所属大学

(3) 大学

	データ構造：	カレッジ
	意味：	学生基本情報管理システムの基本的なデータ構造であり、大学の詳細な情報を定義します。
	構成：	大学番号、大学名、学部長名、大学電話番号、大学が所属するキャンパス、大学

(4) 寮

	データ構造：	寮
	意味：	学生基本情報管理システムの基本的なデータ構造であり、学生の宿泊内容を定義します。
	構成：	寮番号、寮の部屋番号、寮フロア、寮棟番号

(5) 建物及び建物

	データ構造：	建物
	意味：	学生基本情報管理システムの基本的なデータ構造であり、寮の建物の詳細情報を定義します。
	構成：	建物番号、グループ番号、建物カテゴリー、建物が属するキャンパス

(6) キャンパス

	データ構造：	キャンパス
	意味：	学生基本情報管理システムの基本的なデータ構造であり、キャンパス情報を定義します。
	構成：	キャンパス番号、キャンパス名、キャンパス住所

2.3.2 主要なデータ項目の説明

データ項目は主にエンティティの属性に対応しており、学生エンティティと寮エンティティの主なデータ項目の説明を以下に示します。

(1) 学籍番号

	データ項目名:	学生証
	意味：	各生徒を一意に識別する
	エイリアス：	学籍番号、学生証
	タイプ：	文字の種類
	長さ：	最大長は 20 です
	範囲:	最大20桁はすべて9桁です
	値の意味:	最初の 4 桁は学生の入学年を示し、次の数字は学生の大学、クラス、クラス番号、その他の情報を表します。

(2) 寮番号

	データ項目名:	寮番号
	意味：	学校内で寮を一意に識別します
	エイリアス：	寮ID
	タイプ：	文字の種類
	長さ：	4
	範囲:	0000-9999
	値の意味:	最初の 2 桁は建物番号を示し、最後の 3 桁は家屋番号を示します。

(3) 性別

	データ項目名:	性別
	意味：	生徒の性別を特定する
	エイリアス：	なし
	タイプ：	文字の種類
	長さ：	4
	範囲:	男性か女性

他のデータ項目の分析についても同様です。いずれのデータも項目数が多いため、ここでは一つ一つ説明を省略します。

2.3.3 部分処理プロセスの説明

学生基本情報管理データベースを設計する際には、大まかな基本的な処理プロセスを決める必要があります。一般的な処理プロセスには、通常、学生の入学情報のインポート、専攻の割り当て、寮の割り当て、転校などの操作が含まれます。以下に処理工程の一部を説明するが、他の処理工程も同様に処理される。

(1) 入学情報のインポート

	加工プロセス:	入学情報インポート
	例証します:	学生情報入力
	入力：	学生向けの各種基本情報
	出力：	学生の基本情報が入力されています
	対処する：	新入生は登録する前に、基本的な学生情報を入力する必要があります。

(2) 寮の割り当て

	加工プロセス:	寮の割り当て
	例証します:	入学を許可された学生に寮を割り当てる
	入力：	学生、寮番号
	出力：	寮が手配されました
	対処する：	新入生報告後、寮の部屋を手配し、学生情報用紙に寮の対応番号を記入します。

2.4 実現可能性の分析

経済的実現性: このデータベースはパーソナルコンピュータ上で完全に運用でき、個人のローカルディスクが十分に大きければ、大量のデータストレージのニーズを満たすことができます。

技術的実現可能性：システム設計は、上記の分析に基づいて機能の追加、削除、確認、修正を行う必要があるが、機能が複雑ではなく、現在の技術条件で十分にニーズを満たせる。

ユーザーの実現可能性: このデータベースシステムの設計は、情報を直観的に表現し、さまざまなユーザーのさまざまなニーズを満たすことができます。

第3章システム設計

3.1 需要分析に基づいてエンティティ、属性、エンティティ間の関係を決定する

3.1.1 エンティティとその属性の決定

上記の分析の後、このデータベース設計に必要なエンティティは、学生、キャンパス、建物、専攻、キャンパス、寮、学年であることがわかります。

学生: 学生番号、名前、性別、生年月日、民族、ID 番号、所属政党、携帯電話番号などの属性が含まれます。学生情報テーブルの主キーとしては、学籍番号とIDカード番号およびその組み合わせを使用できますが、一般にIDカード番号は長すぎるため、主キー/主コードとして学籍番号を選択します。

プロフェッショナル: 含まれる属性には、プロフェッショナルコードとプロフェッショナル名が含まれます。プロフェッショナルコードを主キーとして使用できます。

キャンパス: キャンパス番号、キャンパス名、キャンパス住所などの属性が含まれます。キャンパス番号を主キーとして使用できます。

寮: 含まれる属性には、寮の部屋番号、寮の建物、寮のフロアが含まれます。

建物: 建物カテゴリ、建物番号、建物が属するキャンパスなどの属性が含まれます。

グレード: 含まれる属性はグレード番号である場合があります。

次の図は、エンティティとそのプロパティを表したものです。

図 3-1 エンティティセットの属性

3.1.2 エンティティ間の関係

学生と専攻の間には所属関係があり、学生と専攻の対応関係はm:1です。

専攻と学部の間には従属関係があり、専攻と学部の対応関係はm:1です。

学生と寮との間には主従関係があり、学生と寮との対応関係はｍ：１である。

生徒と学年の間には従属関係があり、生徒と学年の対応関係はｍ：１である。

寮と建物の間には主従関係があり、寮と建物の対応関係はm:1です。

建物とキャンパスの間には従属関係があり、建物とキャンパスの対応関係はm:1です。

それらの間の関係は、次の図のように要約できます。 (以下に含まれるエンティティの属性はありません。これは、E-R 図を設計するときにマークされます)

図 3-2 エンティティ関連図

エンティティ間の一般的な関係を上の図に示します。

しかし、特定の問題も発生するでしょう。

(1) 問題点1と解決策

質問: 学生からキャンパスまでは 2 つの関係チェーンがあります。つまり、「学生 > 寮 > 建物 > キャンパス」と「学生 > 学年&大学 > キャンパス」です。

解決策は、一連の関係を維持することです。

関係チェーンの 1 つを削除すると、次のようなエンティティ間の単純な関係図が得られます。

図 3-3 エンティティ間の改善された関係図

(2) 問題点2と解決策

質問: 上記のエンティティ間の関係図は機能要件の 1 つを満たしていません。学生は大学があるキャンパスに分散しており、状況に応じて調整される可能性があります。たとえば、コンピュータサイエンス学部は、ある学年ではキャンパス 1 にありますが、2 年目にはキャンパス 3 に移動する場合があります。 )

分析: 大学内の異なる学生が成績に応じて異なるキャンパスの授業に出席する可能性があることを考慮すると、学生は必然的に宿泊施設に滞在し、異なるキャンパスに異なる寮が存在するため、学生はそれぞれの大学のキャンパス内に配置されており、この状況は状況に応じて調整される場合があります。

関連ソリューション: 成績の関係でキャンパスを変更する必要がある場合、物流管理の宿泊施設情報を変更してキャンパスの変更を反映するだけで済みます。

上記の状況を踏まえると、成績は生徒の属性として扱うことができます。最終的なエンティティ関係図を取得します。

図 3-4 エンティティ間の最終的な接続図

3.2 E-Rモデルの設計

3.2.1 ローカル E-R モデルの設計

第 2 章のアプリケーション環境分析によると、学生基本情報管理システムは 3 つの部分に分割できます。

在学状況情報管理システム、学生寮宿泊管理システム、物流寮建物管理システム。

以下は、3 つのシステムの部分的な E-R ダイアグラムの設計です。

(1) 在学状況情報管理モデル

図 3-5 学生ステータスの基本情報関係モデル

(2)学生寮の宿泊管理モデル

図 3-6 学生寮の宿泊管理情報関係モデル

(3) 物流寮運営モデル

図 3-7 物流寮管理情報関係モデル

3.2.2 ローカル E-R 図に基づいて全体の E-R 図を決定する

上記のローカル E-R モデルを変更して、全体的な E-R 図を取得します。

図 3-8 全体 E-R 図

3.2.3 最終的な E-R モデルの最適化と決定

最初に取得された E-R モデルには冗長な転送チェーンや冗長な属性情報が存在しないため、図 3-8 の全体的な E-R 図が最終的な E-R 図モデルになります。

3.3 E-Rモデルからリレーショナルモデルへの変換

3.3.1 変換ルール

(1) エンティティの変換: 各エンティティはリレーションシップスキーマに変換されます。

=エンティティの名前→関係の名前

= エンティティの属性 → 関係の属性

= エンティティの主属性 → 関係のキー

(2) つながりの変換：各つながりを関係パターンに変換します。

① 1:1、1:N とサブクラス間の関係には、別の関係モデルを追加する必要はありません。

②M:N接続には別途関係モデルを追加する必要があります。

別の関係スキーマが追加されていない場合、関係の変換には、関係に関連するエンティティの関係スキーマに対する適切な変更 (通常はキー属性の追加) が必要です。

3.3.2 学生ステータス情報E-R図変換関係モデル

学生と専攻の間には多対 1 の関係があり、「1」エンドエンティティの主属性は、「N」エンドエンティティに対応する関係の外部キー属性として使用されます。専攻の主キー-専攻コードを、学生エンティティの対応する関係の外部キー属性としてグループ化します。

専攻と大学の間の多対 1 の E-R 図の場合、それをリレーショナルモデルに変換し、専門エンティティの対応関係の外部キー属性として大学の主キー - 学生番号をグループ化します。

まとめると、学生ステータス情報の E-R 図は次の関係モデルに変換されます。

学生ステータス情報の関係モデル

学生 (学生番号、名前、性別、学年、年齢、民族、生年月日、所属政党、ID 番号、電話番号) 、プロフェッショナルコード (FK))

専攻 (専門職コード、専攻名、大学番号 (FK))

大学 (大学番号、大学名、学部長の名前、大学の電話番号)

3.3.3 学生寮情報 E-R 図と関係モデル

学生エンティティと寮エンティティの間には多対一の関係があり、寮エンティティの主キーである寮番号が学生エンティティの外部キー属性として使用されます。

学生寮情報のE-R図を以下の関係モデルに変換します。

学生寮情報の関係モデル

学生 (学生番号、名前、性別、年齢、民族、生年月日、所属政党、ID 番号、電話番号、寮)いいえ (FK))

寮 (寮番号、寮の部屋番号、寮の階、建物番号)

3.3.4 物流寮管理 E-R 図と関係モデル

建物エンティティとキャンパスエンティティの間の多対 1 の関係では、キャンパスエンティティの主キーであるキャンパス番号が建物の外部キー属性として使用されます。

物流寮管理E-R図を以下の関係モデルに変換します。

物流寮管理の関係モデル

建物の建物 (建物番号、グループ番号、建物カテゴリ、キャンパス番号 (FK))

校区（校区编号，校区名称，校区地址）

3.3.6总体E-R图转换为关系模式

将上述部分E-R图转换的关系模式进行综合，得到总体的关系模式。

总体关系模式

学生（学号，姓名，性别，年龄，民族，出生日期，政治面貌，身份证号，电话号码，专业代码（FK），宿舍编号（FK））

专业（专业代码，专业名称，学院编号（FK））

学院（学院编号，学院名称，学院院长姓名，学院电话）

宿舍（宿舍编号，宿舍房间号，宿舍楼层，楼栋编号（FK））

楼栋建筑（楼栋编号，组团号，建筑类别，校区编号（FK））

校区（校区编号，校区名称，校区地址）

3.4数据库基本表的设计

根据前面的数据字典和关系模式，现在给出数据库各个基本表的设计。

STUDENT（学生基本信息表）
属性	属性含义	数据类型	数据长度（字节）	备注
STUID	学号	VARCHAR2	20	主键
STUNAME	姓名	VARCHAR2	10	-
GENDER	性别	VARCHAR2	2	-
AGE	年龄	VARCHAR2	2	-
GRADE	年级	VARCHAR2	2	-
NATION	民族	DATE	-	-
BIRTHDAY	出生日期	VARCHAR2	2	-
POLITICAL	政治面貌	VARCHAR2	150	-
IDNUMBER	身份证号	VARCHAR2	30	-
TELNUMBER	电话号码	VARCHAR2	30	-
PROFESSIONALID	专业编号	VARCHAR2	2	外键
COLLEGEID	学院编号	VARCHAR2	2	外键
DORMID	宿舍编号	VARCHAR2	5	外键

DORM（宿舍基本信息表）
属性	属性含义	数据类型	数据长度（字节）	备注
DORMID	宿舍编号	VARCHAR2	5	主键
DORMNAME	房间号	VARCHAR2	5	-
DORMHEIGTHID	楼层	VARCHAR2	10	-
DORMBUILDINGID	宿舍所属楼栋号	VARCHAR2	2	外键

DORMBUILDING（宿舍基本信息表）
属性	属性含义	数据类型	数据长度（字节）	备注
DORMBUILDINGID	楼栋号	VARCHAR2	5	主键
ZUTUNID	组团名	VARCHAR2	30	-
DORMBUILDING NAME	楼栋类别	VARCHAR2	30	-
DORMBUILDNLO CALCAMPUS	楼栋所属校区	VARCHAR2	2	外键

DORMBUILDING（楼栋建筑基本信息表）
属性	属性含义	数据类型	数据长度（字节）	备注
DORMBUILDINGID	楼栋号	VARCHAR2	5	主键
ZUTUNID	组团名	VARCHAR2	30	-
DORMBUILDING NAME	楼栋类别	VARCHAR2	30	-
DORMBUILDNLO CALCAMPUS	楼栋所属校区	VARCHAR2	2	外键

PROFESSIONAL（专业基本信息表）
属性	属性含义	数据类型	数据长度（字节）	备注
PROFESSIONALID	专业代码	VARCHAR2	2	主键
PROFESSIONAL LOCALCOLLEGEID	专业隶属学院	VARCHAR2	2	-
PROFESSIONA LNAME	专业名称	VARCHAR2	200	外键

COLLEGE（学院基本信息表）
属性	属性含义	数据类型	数据长度（字节）	备注
COLLEGEID	学院编号	VARCHAR2	2	主键
COLLEGENAME	学院名称	VARCHAR2	20	-
COLLEGE PRESIDENT	院长	VARCHAR2	5	-
COLLEGE PRESIDENT TELNUMBER	学院电话	VARCHAR2	20	-
COLLEGELOCAL CAMPUSID	学院所处学校ID	VARCHAR2	2	外键

CAMPUS（校区基本信息表）
属性	属性含义	数据类型	数据长度（字节）	备注
CAMPUSUD	校区编号	VARCHAR2	2	主键
CAMPUSNAME	校区名称	VARCHAR2	10	-
ADDRESS	地址	VARCHAR2	10	-

第四章代码与实现

4.1创建各种基本表代码实现

创建基本表的代码

CREATE TABLE CAMPUS (

CAMPUSID VARCHAR2(2) NOT NULL , --校区ID，校区类型和长度约束，不能为空

CAMPUSNAME VARCHAR2(10 BYTE) NOT NULL , --校区名字，字符类型最长为10字节，不能为空

ADDRESS VARCHAR2(100 BYTE) NULL, --校区地址，字符类型最长为100字节，可以为空

CONSTRAINT CAMPUS_PK PRIMARY KEY(CAMPUSID) --设定校区基本表的主键为校区ID

);

ALTER TABLE CAMPUS ADD CONSTRAINT CK_CAMPUS_CAMPUSID

CHECK(CAMPUSID = '1' OR CAMPUSID = '2'); --更改约束条件为校区的ID只能为1或2，根据实际情况电子科技大学有清水河和沙河两个校区而——定。

ALTER TABLE CAMPUS ADD CONSTRAINT CK_CAMPUS_CAMPUSNAME

CHECK(CAMPUSNAME = '清水河校区' OR CAMPUSNAME = '沙河校区'); --约束校区的名字只能为清水——河或者沙河校区

CREATE TABLE COLLEGE ( --创建学院基本表

COLLEGEID VARCHAR2(2) NOT NULL , --学院ID，校区类型和长度约束，不能为空

COLLEGENAME VARCHAR2(20 BYTE) NOT NULL , --学院名称，校区类型和长度约束，不能为空

COLLEGEPRESIDENT VARCHAR2(10 BYTE) NULL , --院长，字符，最长10字节，可为空

COLLEGEPRESIDENTTELNUMBER VARCHAR2(20) NULL ,--学院电话，可为空

--COLLEGELOCALCAMPUSID VARCHAR2(2) NOT NULL ,--学院所处校区ID，不能为空

CONSTRAINT COLLEGE_PK PRIMARY KEY(COLLEGEID)--设置学院ID为学院基本表的主键

--CONSTRAINT COLLEGE_FK FOREIGN KEY(COLLEGELOCALCAMPUSID) REFERENCES CAMPUS(CAMPUSID) --设置校区基本表的校区ID为学院基本表的外键

);

CREATE TABLE DORMBUILDING( --创建楼栋建筑基本表

DORMBUILDINGID VARCHAR2(5) NOT NULL , --楼栋号，变长字符类型，不超过5字节，不为空

ZUTUANID VARCHAR2(30) NULL,--组团号，变长字符类型，不超过30字节，可为空

DORMBUILDINGNAME VARCHAR2(30 BYTE) NOT NULL ,--楼栋类别，变长字符类型，不超过30字节，不可为空

CAMPUSID VARCHAR2(2) NOT NULL ,

CONSTRAINT DORMBUILDING_PK PRIMARY KEY(DORMBUILDINGID),

CONSTRAINT DORMBUILDING_FK FOREIGN KEY(CAMPUSID) REFERENCES CAMPUS(CAMPUSID)

);

ALTER TABLE DORMBUILDING ADD CONSTRAINT CK_DORMBUILDING_CAMPUSID

CHECK(CAMPUSID = '1' OR CAMPUSID = '2');

CREATE TABLE DORM ( --创建宿舍基本表

DORMID VARCHAR2(5) NOT NULL ,--宿舍编号，变长字符类型，不超过5字节，不可为空

DORMNAME VARCHAR2(5 BYTE) NOT NULL ,--房间号，变长字符类型，不超过5字节，不可为——空

DORMHEIGTHID VARCHAR2(10) NOT NULL , --宿舍楼层，不可为空

DORMBUILDINGID VARCHAR2(5) NOT NULL ,--宿舍所属楼栋号，不能为空

CONSTRAINT DORM_PK PRIMARY KEY(DORMID),--设置宿舍编号为宿舍基本表的主键

CONSTRAINT DORM_FK FOREIGN KEY(DORMBUILDINGID) REFERENCES DORMBUILDING(DORMBUILDINGID)--设置建筑楼栋的主键为宿舍基本表的外键

);

CREATE TABLE PROFESSIONAL ( --创建专业基本表

PROFESSIONALID VARCHAR2(4) NOT NULL , --专业代码，不可为空

PROFESSIONALLOCALCOLLEGEID VARCHAR2(2) NOT NULL ,--专业隶属学院，不可为空

PROFESSIONALNAME VARCHAR2(100) NOT NULL ,--专业名称，不可为空

CONSTRAINT PROFESSIONAL_PK PRIMARY KEY(PROFESSIONALID),--设置专业代码为主键

CONSTRAINT PROFESSIONAL_FK FOREIGN KEY(PROFESSIONALLOCALCOLLEGEID) REFERENCES COLLEGE(COLLEGEID)--设置学院基本表中的主键为专业基本表的外键

);

CREATE TABLE STUDENT --创建学生基本表

(

STUID VARCHAR2(20) NOT NULL, --学号，不可为空

STUNAME VARCHAR2(10) NOT NULL,--学生姓名，不可为空

GENDER VARCHAR2(2) NOT NULL,--性别：男或者女

AGE NUMBER(2) NOT NULL,--年龄：0~100

GRADE VARCHAR2(4) NOT NULL,--年级：大一~博五

NATION VARCHAR2(2) NOT NULL, --民族，不可为空

BIRTHDAY DATE,--出生日期，DATE类型

POLITICAL VARCHAR2(10),--政治面貌

IDNUMBER VARCHAR2(30) NOT NULL,--身份证号

TELNUMBER VARCHAR2(30) NOT NULL,--电话号码

PROFESSIONALID VARCHAR2(4) NOT NULL,--专业代码

--COLLEGEID VARCHAR2(2) NOT NULL,--学院编号

DORMID VARCHAR2(5) NOT NULL,--宿舍编号

CONSTRAINT STUDENT_PK PRIMARY KEY(STUID),--设置学号为学生基本表的主键

CONSTRAINT STUDENT_FK1 FOREIGN KEY(PROFESSIONALID) REFERENCES PROFESSIONAL(PROFESSIONALID),--设置专业基本表的主键为学生基本表的外键

--CONSTRAINT STUDENT_FK2 FOREIGN KEY(COLLEGEID) REFERENCES COLLEGE10(COLLEGEID),--设置

CONSTRAINT STUDENT_FK2 FOREIGN KEY(DORMID) REFERENCES DORM(DORMID)--设置宿舍基本表的主键为学生基本表的外键

);

ALTER TABLE STUDENT ADD CONSTRAINT CK_STUDENT_GENDER

CHECK(GENDER = '男' OR GENDER= '女'); --更改约束条件，取值范围为男或者女

ALTER TABLE STUDENT ADD CONSTRAINT CK_STUDENT_AGE

CHECK(AGE >=0 AND AGE<=100);

4.2插入数据

插入数据的代码

INSERT INTO CAMPUS VALUES ('1', '清水河校区', '四川省成都市郫都区西源大道合作街道2006号');

INSERT INTO CAMPUS VALUES ('2', '沙河校区', '四川省成都市成华区建设北路二段4号');

INSERT INTO COLLEGE VALUES ('01', '信息与通信工程学院','孔院长','01347265283');

INSERT INTO PROFESSIONAL VALUES ('0****3', '01','**工程');

INSERT INTO DORMBUILDING VALUES ('2*', '**团','学知苑','1');

INSERT INTO DORM VALUES ('27633', '6**','*楼','27');

INSERT INTO STUDENT VALUES ('20200888', '**', '*',20,'大三','汉',TO_DATE('2002-**-**','*******dd'),'共青团员','****','***','0103','27**');

4.3创建视图

学生宿舍管理视图

---创建视图，学生宿舍管理视图

CREATE VIEW STU_DORM

SELECT E1.STUID AS 学号,E1.STUNAME AS 姓名,E1.TELNUMBER AS 联系方式,E2.DORMNAME AS 宿舍房间,E3.DORMBUILDINGID AS 楼栋号,E3.ZUTUANID AS 组团,E4.CAMPUSNAME AS 所在校区

FROM STUDENT E1, DORM E2,DORMBUILDING E3,CAMPUS E4

WHERE E1.DORMID=E2.DORMID AND E2.DORMBUILDINGID=E3.DORMBUILDINGID AND E3.CAMPUSID=E4.CAMPUSID;

教务处管理视图

---创建视图，教务处可以显示的学生的视图

CREATE VIEW STU_INFO

SELECT E1.STUID AS 学号,E1.STUNAME AS 姓名,E1.TELNUMBER AS 联系方式,E1.GRADE AS 年级,E2.PROFESSIONALNAME AS 专业名称,E3.COLLEGENAME AS 所属学院,E6.CAMPUSNAME AS 所在校区

FROM STUDENT E1, PROFESSIONAL E2,COLLEGE E3,DORM E4,DORMBUILDING E5,CAMPUS E6

WHERE E1.PROFESSIONALID=E2.PROFESSIONALID AND E2.PROFESSIONALLOCALCOLLEGEID=E3.COLLEGEID AND E1.DORMID=E4.DORMID AND E4.DORMBUILDINGID=E5.DORMBUILDINGID AND E5.CAMPUSID=E6.CAMPUSID;

第五章测试

注明：本章节没有结果截图，可以根据图题信息自己截取，因为信息涉及个人隐私就没有放出来

5.1基本表创建结果和数据

5.1.1基本表创建结果

（1）校区基本表

图5-1 校区基本表

（2）学院基本表

图5-2 学院基本表

（3）专业基本表

图5-3 专业基本表

（4）宿舍基本表

图5-4 宿舍基本表

（5）楼栋建筑基本表

图5-5 楼栋建筑基本表

（6）学生基本表

图5-6 学生基本表

5.1.2基本表存储信息的生成

图5-7 学生基本表存储的数据

图5-8 专业基本表存储的数据

图5-9

学院基本表存储的数据

图5-10

宿舍基本表存储的数据

图5-11

楼栋建筑基本表存储的数据

图5-12 校区基本表存储的数据

5.2视图的创建和测试

（1）学生住宿管理信息视图

图5-13

学生住宿管理信息视图创建成功截图

图5-14学生住宿管理信息视图

（2）学生学籍信息视图

图5-15

学生学籍信息视图创建成功截图

图5-16

学生学籍信息视图

5.3建立表的关系模型图

图5-17 多张表的关系模型图

5.4应用便利性测试

5.4.1查询便利性测试

应用场景1：学院教务处管理人员查询某一个专业所有的学生

SELECT E1.*

FROM STUDENT E1,PROFESSIONAL E2

WHERE E1.PROFESSIONALID=E2.PROFESSIONALID AND E2.PROFESSIONALNAME='**工程';

结果如下：

图5-18查询结果截图

应用场景二：后勤管理人员查询学生信息（查询视图）

SELECT *

FROM STU_DORM

WHERE "姓名"='**'

结果：

图5-19

查询结果截图

5.4.2修改便利性测试

场景一：学生因为转学院信息变更

INSERT INTO COLLEGE VALUES('02','电子工程学院','***','246***838');

INSERT INTO PROFESSIONAL VALUES('0201','02','电子信息与集成电路专业');

UPDATE STUDENT SET PROFESSIONALID='0201';

SELECT *

FROM STU_INFO

WHERE "学号"='**';

结果：

图5-20 修改信息后查询视图截图

5.5测试结果分析以及结论

本数据库查询和修改以及删除信息都十分的高效和便利。从测试的结果来看，本数据库可以方便的创建视图，以及修改基本表的数据，满足了后勤管理人员，教务管理人员，辅导员，学生等多用户的需求。

5.6相关错误记录和解决方案

（1）删除表的时候表中有属性充当了外键报错

图5-21 删除表时报错截图

相应解决方案：删除表的时候，要注意删除的顺序，删除的表的属性不会被其他表充当外键或者有其他联系，当然可以采用级联删除。

（2）插入数据时顺序不对报错

图5-22 插入数据时错误截图

相应解决方案：插入数据的时候，要注意插入的顺序，需要外键的需要最后再进行插入。

第六章总结

6.1思考题

1、请举例说明本次设计中的数据库表如何来满足数据库三大范式。

第一范式要求：基本表的属性不可再分。很显然以上基本表里面的属性都是不可以再分的。

第二范式要求非主属性完全函数依赖于主属性。由于本数据库里面的候选码是单属性，每一张基本表的逐渐都是单属性，所以根据推论（关系模式符合1NF，并且候选码都是单属性，则一定是第二范式），以上设计满足第二范式。

第三范式是满足第二范式，消除了非主属性对码的传递函数依赖关系。

分析每一张表：

学生基本表，主属性只有学号和身份证号，但是二者互相决定，其余的非主属性都不能相互决定，在表中不存在任何的函数传递依赖。

专业基本表，主属性只有专业代码，非主属性之间又不能相互决定，所以也不存在函数传递依赖。

后面的学院基本表，宿舍基本表也都不存在函数传递依赖。

楼栋建筑和校区基本表也不存在函数传递依赖。

校区基本表：校区编号和校区名称以及校区地址都是可以互相决定的，都是一对一的关系，虽说有校区编号"校区名称"校区地址，但是校区名称"校区编号，所以不存在函数传递依赖，楼栋建筑基本表的分析也是如此。

综上，数据库表的设计满足数据库三大范式。

2、用一张视图来展示学生的基本信息、所在学院、所住寝室、所在校区的情况。请写出创建视图的代码，以及查询该视图信息的 SELECT 命令和结果截图。

创建视图的代码：

CREATE VIEW SRU2_DORM_INFO

SELECT E1.*,E3.COLLEGENAME,E4.DORMNAME,E5.ZUTUANID,E6.CAMPUSNAME

FROM STUDENT E1,PROFESSIONAL E2,COLLEGE E3,DORM E4,DORMBUILDING E5,CAMPUS E6

SELECT查询代码：

SELECT *

FROM SRU2_DORM_INFO

WHERE STUID='2020******'

6.2总结与心得体会

在本次实验过程中，通过对学生基本信息数据库进行设计，从基本的需求分析做起，采用自上而下的设计思路，锻炼了自己的管理和分层次设计的能力。

其次，对E-R模型有了更加深入的了解，对于一个复杂的关系模式的设计，可以分解成许多局部的实体或者实体之间的关联，然后画出局部的E-R图，转换成关系模式之后，然后在设计出总的关系模式。

在整个数据库的设计过程当中，运用软件工程的思想进行设计，使得自己节省了很多的时间。