MySQL データベースの設計と実装

レベル 1: 概念モデルから MySQL 実装まで

ミッションの詳細

確立された概念モデルを MySQL の物理実装に変換します。

関連情報

1. データベース設計のフェーズと各フェーズのタスク、
2. 概念モデル、
3. 論理モデルとその概念モデルとの関係、
4. DBMS への物理実装。

データベース設計のフェーズと各フェーズのタスク

データベースの設計は、大きく次の段階に分かれます。
要件分析
ビジネス要件に従ってアプリケーション システムに含まれるデータ (情報) を決定し、要件を処理してデータ ノット、データ構造、データを含むデータ ディクショナリを形成します。フロー、データ ストレージ、データ 処理プロセスなどのドキュメント
の概念構造設計
主な仕事はデータのモデル化です。リレーショナル データベース アプリケーション システムでは、主に ER 図はデータとデータ間の関係を記述するために使用されます (もちろん、一部のユーザーは ER 図を使用してデータとデータ間の関係を記述します) UML クラス図)。ER図の表現方法には2種類あり、1つは台湾・高雄出身のピーター・チェン氏(ルイジアナ州立大学教授)が提唱したチェンER図であり、教科書では主にこのER図が教えられています。図 1 は、教科書で一般的に使用される学生のコース選択システムの概念モデルをチェンの ER 図を使用して表現しています。

学生の進路選択の概念モデル

図1 学生の選択科目
Chen の ER 図は多くのスペースを占有し、システム内に多数のエンティティと属性がある場合、エンティティを表す各長方形から広がる楕円形 (属性を表す) により、モデル全体が混乱して混雑したように見えます。そこで、後のクロウズフット(カラスの足跡)型のER図が登場しました。図 2 は、クロウズフット ER 図を使用して学生と学部の関係を表しています。

カラスの足跡

図2 クロウズフットER図
図 2 は、学部と学生の間の 1 対多の関係を示しており、2 つのエンティティの属性がそれぞれのエンティティ名の下にリストされています。2 つのエンティティを結ぶには、両端にマークを付けた線を使用して、2 つのエンティティ間のつながりを表現します。線の中央に連絡先名が記述されるため、スペースを節約できます。1 対多の接続の形状がカラスの足に非常に似ているため、カラスの足と呼ばれることに注意してください (ただし、ほとんどの鳥の足はこれに似ています)。

論理構造設計
主な仕事はER図をリレーショナルモデルに変換することです。概念構造から論理構造への変換にはルールがあり、それは 2 つのエンティティ間の接続に関係しており、教科書ではすでに十分に説明されています。クロウズフット型 ER 図の利点の 1 つは、元の図にわずかな変更を加えて (たとえば、1 つの端末のメイン コードを複数の端末に直接追加するなど)、論理構造に変換できることです。メイン コード、外部コード、インデックスを追加し、DBMS にリストされているすべての型をすぐに物理モデルにすることができます。これは、コンピュータがデータベース オブジェクトを自動的に作成するのに便利です。図 3 では、各属性のデータ型を指定し、外側のコードを定義しています。

パイスカルモデル

図 3 物理モードに近いカラスの足跡モデル

物理構造設計
物理構造設計の主な作業は、論理構造に基づいて記憶構造とアクセス方法を決定し、特定の DBMS のすべてのデータ型を決定することです。

導入と運用保守
選択したDBMS上で、データオブジェクトの作成、データの初期化、テスト実行、継続的なデバッグの過程でシステムの改善を行い、継続的な改善と保守を行います。

ERWIN、Navicat、Microsoft Visio、Draw.IO、MySQL Workbench など、ほとんどのモデリング ツールはクロウズ フットをサポートしています。Visio とdraw.io も Chen の ER 図をサポートしています。上記のツールのうち、無料なのは Draw.IO と MySQL Workbench だけです。ERWIN、Navicat、および MySQL Workbench は、構築されたデータベース、逆エクスポート モデル (通常は物理モデル) に基づくリバース エンジニアリング、つまりリバース エンジニアリングもサポートします。Navicat は、論理モデルと概念モデルへの継続的なリバースをサポートします。基本的に、リバース エンジニアリングに基づいて、DMBS の特定のデータ型を置き換えます。たとえば、varchar(50) を string に変更します。これは論理モデルであり、論理モデル内のすべての外部コード列を削除すると、概念モデルになります。概念モデルにはデータ型に注釈を付けることができない場合があります。ただし、運用環境では、モデルを表現するためにソフトウェアがよく使用され、実際、文字列、整数、浮動小数点数、日付時刻、ブール値などの一般的なデータ型が概念モデルからマークされています。

プログラミング要件

このレベルのタスクは、構築された論理モデルに従って MySQL の実装を完了することです。論理 ER 図を図 3 に示します。

予約システムのER図

図3 航空券予約システムの概念モデルのER図
説明: この絵はdraw.ioで描かれており、ソフトウェアをインストールしなくてもブラウザのアドレスバーにdraw.ioと入力することで呼び出すことができます。

アプリケーションの背景の紹介

これは航空券予約システムであり、システムでは次のエンティティを考慮する必要があります:
1. ユーザー (利用者)
ユーザーには 2 種類があり、航空券を予約できる一般ユーザーと、航空券の運用を維持管理する権限を持つ管理ユーザーがあります。システム全体。わかりやすくするために、2 つのタイプのユーザーがマージされ、admin_tag タグによって区別されます。ユーザー属性 (ビジネス上の制約を含む) は次のとおりです。
ユーザー ID: user_id int プライマリ コード、自動インクリメント
名: firstname varchar(50) を空にすることはできません
姓: lastname varchar(50) を空にすることはできません
誕生日: 生年月日を空にすることはできません
性別: sex char(1) 空にすることはできません 電子
メール: email varchar(50)
連絡先番号: Telephone varchar(30)
ユーザー名: username varchar(20) 空にすることはできず、繰り返すことはできません
パスワード:password char(32) 空にすることはできません
emptyAdministrator フラグ: admin_tag tinyint デフォルト値 0 (非管理者)、空にすることはできません

2. 乗客
ユーザーは必ずしも自分でチケットを購入するためにシステムにログインするわけではないため、ユーザーと乗客の情報は別々に保存されます。属性は次のとおりです。
乗客番号:乗客_id int自動インクリメント、メインコード
文書番号: id char(18) 空または繰り返しはできません 名
: firstname varchar(50) 空にすることはできません
姓: lastname varchar(50) はできません空の
電子メール: mail varchar(50)
電話: Phone varchar(20) null 不可
性別: sex char(1) null 不可
誕生日: 生年月日

3. 空港 (空港) には
次の属性があります。
数値: Airport_id int 自動インクリメント、メイン コード
ICAO コード: iata char(3) 空ではない、世界で一意
IATA コード: icao char(4) 空ではない、一意の
空港世界の名前: name varchar(50) 空にすることはできません、共通インデックス
都市: city varchar(50)
国: country varchar(50)
緯度: 緯度 10 進数 (11,8)
経度: 経度 10 進数(11,8)
すべての空港世界には独自のIATAコードとICAOコードがあり、IATAは3文字、ICAOは4文字です。たとえば、首都空港の(IATA、ICAO)は(PEK、ZBAA)、大興空港は(PKX、ZBAD)、天河空港は(WUH、ZHHH)となります。出発地と到着地の両方が IATA によって航空機の登録プレートに表示されます。空港の位置を地図上に表示するには、緯度経度の情報を記録する必要があります。

4. 航空会社 (airline) に
は次の属性があります。
番号:airline_id int 自動インクリメント、メイン コード
名:name varchar(30) null 不可
ICAO コード:iata char(2) null 不可、世界的に一意の IATA
航空会社コードは 2 桁です。たとえば、中国東方航空の場合は MU、中国国際航空の場合は CA、中国南方航空の場合は CZ などです。通常、便名の前には、所属する航空会社の IATA コードが付加されます。

5. 民間航空航空機 (飛行機) には
次の属性があります:
番号: 飛行機 ID int 自己インクリメント、メイン コード
タイプ: B737-300、A320-500 など、type varchar(50) を空にすることはできません。 座席
: 定員 smallint はできません。空の
ID: 識別子 varchar( 50) null 不可

6. 定期便のスケジュール (flightschedule)
便は通常、週ベースで手配されます。たとえば、月曜と金曜の週 2 便です。
属性があります:
フライト番号: Flight_no char(8) マスター コード
出発時刻: 出発時刻は空ではありません
到着時刻: 到着時刻は
空ではありません 飛行時間: 期間 smalint は空ではありません
月曜日: 月曜日 tinyint デフォルト 0
火曜日: 火曜日 tinyint デフォルト 0
水曜日: wednesday tinyint デフォルト 0
木曜日: thursday tinyint デフォルト 0
金曜日: friday tinyint デフォルト 0
土曜日: saturday tinyint デフォルト 0
日曜日: sunday tinyint デフォルト 0
飛行時間は通常、分単位で測定されます。

7. フライトスケジュール(フライト)
フライトは、通常のフライトスケジュールに基づいて手配されます。ただし、スケジュールは静的ではなく、すべての定期便が実際に離陸するわけではなく、常に予定時刻に離陸するわけでもないため、実際の便は個別に手配して記録する必要があります。
記録される情報は次のとおりです。
フライト番号: Flight_id int 自動インクリメント、マスター コード
出発時刻: 出発日時が空ではありません
到着時刻: 到着日時が空ではありません
飛行時間: 継続時間 smallint が
空で一部のシステムでは、フライトの緯度も表示されますここでは、リアルタイムの飛行情報を簡略化して削除しました。

8. 航空券(チケット)
ユーザーは、自分自身または親戚や友人のために、特定のフライトの航空券を購入することができます。チケットの属性は次のとおりです。
チケット番号: ticket_id int 自己インクリメント、メイン コード
座席番号: Seat char(4)
価格: 価格 10 進数 (10,2) を空にすることはできません

9. エンティティ間の接続
エンティティ間の接続は、ER 図で明確にマークされています。

  • 各航空会社には母港(空港)があり、基地とも呼ばれます。大きな空港は複数の会社の拠点である場合がありますが、小さな空港はどの航空会社の拠点でもない場合があります。
  • 各フライトは 1 つの航空会社に属し、1 つの航空会社が多数のフライトを持つことができます。
  • あらゆる民間航空航空機は航空会社に属しており、航空会社は複数の航空機を保有することができます。
  • 各航空機は複数のフライトを飛行することができ、1 つのフライトは 1 つの航空機によって運航されます。
  • 1 つのフライトでは、航空機の種類に応じて複数のチケットを販売できます。チケットは特定のフライトのチケットです。
  • ユーザーはチケットを複数回予約でき、乗客は飛行機に何度も乗ることができます。航空券は、ユーザーが特定の乗客のために購入した特定のフライトの航空券である必要があります。つまり、チケット情報は乗客に関連するだけでなく、購入者情報も記録されます(ただし、両者は同一人物の場合もあります)。簡単にするために、注文時間は考慮されていません。
  • 定期的に計画されたフライトであっても、実際のフライトであっても、ある空港から出発し、別の空港に到着します。しかし、空港は多くのフライトの出発地にもなりますし、多くのフライトの目的地にもなります。

上記の情報と与えられた ER 図に基づいて、データベースの構築、テーブルの作成、主キー、外部キー、インデックスの作成、デフォルトの指定、空でないことなどの制約を含む、MySQL で Flight_booking を実装するためのステートメントを与えてください。すべてのインデックスは BTREE を使用します。すべての制約の名前は必須ではありません。すべての外側のコードは、メイン コードと同じ名前を持ちます。例外が 2 つあります。定期便と飛行便の両方に出発空港と到着空港が含まれており、外側のキーの名前が主キーと同じであるため、同じテーブル内に同じ名前の 2 つの列が存在します。したがって、出発空港名 from と到着空港名 TO の 2 つの外側コードは例外として扱われます。
注: すべてのテーブル名と列名には大文字が含まれません。カラム名はキーワードと同じ名前になっていますので、適切に扱ってください。一度の評価では合格しない可能性があります。コードを修正して繰り返し再実行する必要がある状況を考慮してください。

上の図が十分に明確ではないと思われる場合は、https:
//gitee.com/kylin8575543/db2022-spring
にアクセスして、トレーニングに必要なデータ パッケージをダウンロードするか、このドキュメントを直接表示できます:
https:/ /gitee.com/kylin8575543/db2022-spring/blob/master/flightbooking.png

右側のコード ファイルにステートメントを入力し、評価のために送信してください。

試験指導

評価プログラムはコード ファイルを実行し、すべてのデータベース オブジェクトが期待される結果と完全に一致しているかどうかを確認します (主キー、外部コード、デフォルト、および一意を含むすべての制約の名前は評価に含まれません)。


ミッションを始めましょう。成功を祈っています!

参照コード

 # 请将你实现flight_booking数据库的语句写在下方:
 
drop database if exists flight_booking; 
create database flight_booking; 
use flight_booking;
 
SET NAMES utf8mb4; 
SET FOREIGN_KEY_CHECKS = 0;
 
DROP TABLE IF EXISTS airline ; CREATE TABLE airline ( airline_id int NOT NULL AUTO_INCREMENT, name varchar(30) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, iata char(2) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, airport_id int NOT NULL, PRIMARY KEY ( airline_id ) USING BTREE, UNIQUE INDEX iata_unq ( iata ) USING BTREE, INDEX base_airport_idx ( airport_id ) USING BTREE, CONSTRAINT airline_ibfk_1 FOREIGN KEY ( airport_id ) REFERENCES airport ( airport_id ) ON DELETE RESTRICT ON UPDATE RESTRICT ) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;
 
DROP TABLE IF EXISTS airplane ; CREATE TABLE airplane ( airplane_id int(0) NOT NULL AUTO_INCREMENT, type varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, capacity smallint(0) NOT NULL, identifier varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, airline_id int(0) NOT NULL,
PRIMARY KEY ( airplane_id ) USING BTREE, INDEX airplane_ibfk_1 ( airline_id ) USING BTREE, CONSTRAINT airplane_ibfk_1 FOREIGN KEY ( airline_id ) REFERENCES airline ( airline_id ) ON DELETE RESTRICT ON UPDATE RESTRICT ) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;
 
DROP TABLE IF EXISTS airport ; CREATE TABLE airport ( airport_id int NOT NULL AUTO_INCREMENT, iata char(3) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, icao char(4) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, name varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, city varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL, country varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL, latitude decimal(11, 8) NULL DEFAULT NULL, longitude decimal(11, 8) NULL DEFAULT NULL, PRIMARY KEY ( airport_id ) USING BTREE, UNIQUE INDEX iata_unq ( iata ) USING BTREE, UNIQUE INDEX icao_unq ( icao ) USING BTREE, INDEX name_idx ( name ) USING BTREE ) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;
 
 
DROP TABLE IF EXISTS passenger ; CREATE TABLE passenger ( passenger_id int NOT NULL AUTO_INCREMENT, id char(18) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, firstname varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, lastname varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, mail varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL, phone varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, sex char(1) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, dob date NULL DEFAULT NULL, PRIMARY KEY ( passenger_id ) USING BTREE, UNIQUE INDEX id_unq ( id ) USING BTREE ) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;
 
 
DROP TABLE IF EXISTS ticket ; CREATE TABLE ticket ( ticket_id int NOT NULL AUTO_INCREMENT, flight_id int NOT NULL, seat char(4) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL, passenger_id int NOT NULL, price decimal(10, 2) NOT NULL, user_id int NOT NULL, PRIMARY KEY ( ticket_id ) USING BTREE, INDEX flight_idx ( flight_id ) USING BTREE, INDEX passenger_idx ( passenger_id ) USING BTREE, INDEX ticket_ibfk_3 ( user_id ) USING BTREE, CONSTRAINT ticket_ibfk_1 FOREIGN KEY ( flight_id ) REFERENCES flight ( flight_id ) ON DELETE RESTRICT ON UPDATE RESTRICT, CONSTRAINT ticket_ibfk_2 FOREIGN KEY ( passenger_id ) REFERENCES passenger ( passenger_id ) ON DELETE RESTRICT ON UPDATE RESTRICT, CONSTRAINT ticket_ibfk_3 FOREIGN KEY ( user_id ) REFERENCES user ( user_id ) ON DELETE RESTRICT ON UPDATE RESTRICT ) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;
 
 
 
DROP TABLE IF EXISTS user ; CREATE TABLE user ( user_id int NOT NULL AUTO_INCREMENT, firstname varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, lastname varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, dob date NOT NULL, sex char(1) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, email varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,
phone varchar(30) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL, username varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, password char(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, admin_tag tinyint NOT NULL DEFAULT 0, PRIMARY KEY ( user_id ) USING BTREE, UNIQUE INDEX user_unq ( username ) USING BTREE ) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic; SET FOREIGN_KEY_CHECKS = 1;
 
 
DROP TABLE IF EXISTS flightschedule ; CREATE TABLE flightschedule ( flight_no char(8) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, `from` int NOT NULL, `to` int NOT NULL, departure time NOT NULL, arrival time NOT NULL, duration smallint NOT NULL,
airline_id int NOT NULL, monday tinyint NULL DEFAULT 0, 
tuesday tinyint NULL DEFAULT 0, 
wednesday tinyint NULL DEFAULT 0, 
thursday tinyint NULL DEFAULT 0, friday tinyint NULL DEFAULT 0, saturday tinyint NULL DEFAULT 0, sunday tinyint NULL DEFAULT 0, 
PRIMARY KEY ( flight_no ) USING BTREE, 
INDEX from_idx ( `from` ) USING BTREE, 
INDEX to_idx ( `to` ) USING BTREE, 
INDEX airline_idx ( airline_id ) USING BTREE, 
CONSTRAINT flightschedule_ibfk_1 FOREIGN KEY ( `from` ) REFERENCES airport ( airport_id ) ON DELETE RESTRICT ON UPDATE RESTRICT, CONSTRAINT flightschedule_ibfk_2 FOREIGN KEY ( `to` ) REFERENCES airport ( airport_id ) ON DELETE RESTRICT ON UPDATE RESTRICT, CONSTRAINT flightschedule_ibfk_3 FOREIGN KEY ( airline_id ) REFERENCES airline ( airline_id ) ON DELETE RESTRICT ON UPDATE RESTRICT ) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;
 
DROP TABLE IF EXISTS flight ; CREATE TABLE flight ( flight_id int NOT NULL AUTO_INCREMENT, flight_no char(8) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, `from` int NOT NULL, `to` int NOT NULL,
departure datetime NOT NULL, arrival datetime NOT NULL, duration smallint NOT NULL, airline_id int NOT NULL, airplane_id int NOT NULL, 
PRIMARY KEY ( flight_id ) USING BTREE, 
INDEX from_idx ( `from` ) USING BTREE, 
INDEX to_idx ( `to` ) USING BTREE, 
-- INDEX departure_idx ( departure ) USING BTREE, 
-- INDEX arrivals_idx ( arrival ) USING BTREE, 
INDEX airline_idx ( airline_id ) USING BTREE, 
INDEX airplane_idx ( airplane_id ) USING BTREE, 
INDEX flightno ( flight_no ) USING BTREE, 
CONSTRAINT flight_ibfk_1 FOREIGN KEY ( `from` ) REFERENCES airport ( airport_id ) ON DELETE RESTRICT ON UPDATE RESTRICT, CONSTRAINT flight_ibfk_2 FOREIGN KEY ( `to` ) REFERENCES airport ( airport_id ) ON DELETE RESTRICT ON UPDATE RESTRICT, CONSTRAINT flight_ibfk_3 FOREIGN KEY ( airline_id ) REFERENCES airline ( airline_id ) ON DELETE RESTRICT ON UPDATE RESTRICT, CONSTRAINT flight_ibfk_4 FOREIGN KEY ( airplane_id ) REFERENCES airplane ( airplane_id ) ON DELETE RESTRICT ON UPDATE RESTRICT, CONSTRAINT flight_ibfk_5 FOREIGN KEY ( flight_no ) REFERENCES flightschedule ( flight_no ) ON DELETE RESTRICT ON UPDATE RESTRICT ) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;
 
 
SET FOREIGN_KEY_CHECKS = 1;

レベル 2: 要件分析から論理モデルまで

ミッションの詳細

このレベルのタスク:
アプリケーション シナリオのビジネス要件の説明に従って、ER 図を完成させ、リレーショナル モデルに変換します。
設計書類の提出

ビジネス機能の説明

劇場管理システムを設計します。映画館は現在の上映ホールと映画を手配し、顧客は到着後、任意のシーンの映画チケットを購入し、該当する上映ホールに入り鑑賞することができます。システムには次のエンティティ セットがあります。

  1. 映画 (movie): 属性には、識別番号 (movie_ID)、映画名 (title)、タイプ (type)、期間 (runtime)、プレミア公開日 (release_date)、監督名 (director)、主演者名 (starring) が含まれます。
  2. 顧客(customer):属性には、識別番号(c_ID)、名前(name)、携帯電話番号(phone)が含まれます。
  3. 講堂(ホール):属性には、識別番号(hall_ID)、投影モード(mode)、収容人数、および場所が含まれます。
  4. スケジュール(schedule):属性には、識別番号(schedule_ID)、日付(date)、時刻(time)、チケット価格(price)、投票数(number)が含まれます。
  5. 映画チケット(ticket):属性には識別番号(ticket_ID)と座席番号(seat_num)が含まれます。エンティティ間の関係は次のように説明されます: ①. 顧客と映画チケットの間には 1 対多の購入関係があります。各顧客は複数の映画チケットを購入することができ、各映画チケットは 1 人の顧客によって購入されます。②. ムビチケとシーンの間には多対一の関係があります。ムビチケは 1 つのシーンにのみ属しますが、シーンには複数のムビチケがあります。③.虚飾と映画の間には一対多の関係がある。各シーンで 1 つの映画が上映され、各映画を複数のシーンで上映することもできます。④. シーンと講堂は 1 対多の関係になります。各シーンは 1 つの映写ホールにあり、各映写ホールには複数のシーンを配置できます。

ミッション要件

  1. 上記の要件に従って ER 図を作成します。
  2. 対応する関係スキーマを指定します。

モデリングツールでモデリングする場合はモデルを画像として保存し、手動で描画する場合は写真を撮るか、画像に署名するか、電子署名を追加してください。画像ファイルの名前は ersolution.jpg としてください。そして、イメージ ファイルをインターネット (github や gitee 上のオープン ソース プロジェクト、または直接アクセスできる場所など) にアップロードします。右側のエディタの 2 行目に、画像にアクセスするための URL を入力します。URL は、(特定の Web ページで画像が見つかるのではなく) 画像を直接見つける必要があります。つまり、URL をクリックして、直接絵を描きます。

次に、ファイル エディタでリレーショナル スキーマを書き込みます。
リレーションシップモデルの表現形式は、
学生(学籍番号、氏名、性別、生年月日、学部ID)、メインコード:(学籍番号)、アウターコード:(学部ID)を指し、
純粋な中国語記号は使用しません。

試験指導

評価プログラムは、ドキュメントが提出されているかどうかを確認します。設計のマルチソリューションの性質により、評価プログラムは特定のスコアを与えることはできません。ドキュメントが提出され、関係モデルが与えられている限り、スコアは次のようになります。最初に割り当てられます。手動によるレビューの後、完了に応じて、必要に応じて特定のポイント値が合計スコアから差し引かれます (または差し引かれません)。


ミッションを始めましょう。成功を祈っています!

コードリファレンス

 请给出ER图文件存放的URL:
https://free.wzznft.com/i/2023/05/18/ersolution.jpg
 以下给出关系模式:

电影(movie)(movie_ID, title, type, runtime, release_date, director, starring), 主码:(movie_ID)

顾客(customer)(c_ID, name, phone), 主码:(c_ID)

放映厅(hall)(hall_ID, mode, capacity, location), 主码:(hall_ID)

排场(schedule)(schedule_ID, date, time, price, number, hall_ID, movie_ID), 主码:(schedule_ID),外码:(hall_ID) 参照放映厅(hall)(movie_ID) 参照电影(movie)

电影票(ticket)(ticket_ID, seat_num, c_ID, schedule_ID), 主码:(ticket_ID),外码:(c_ID) 参照顾客(customer)(schedule_ID) 参照排场(schedule)

画像のバックアップ
ER図

レベル 3: モデリング ツールの使用

ミッションの詳細

このレベルのタスク:
MySQL Workbench のフォワード エンジニアリング機能を使用して、構築されたモデル ファイルを SQL スクリプトに自動的に変換します。

関連情報

このタスクを完了するには、
1. 一般的に使用されるモデリング ツールとその特徴、
2. モデリング用のツールの使い方を学ぶ、
3. フォワード エンジニアリングとリバース エンジニアリングを習得する必要があります。

モデリングツールの紹介

1. ERWIN
erwin Data Modeler は、直感的な設計とアーカイブ機能を備えた業界をリードするデータ モデリング ソリューションで、企業全体のあらゆる保管場所にあるあらゆるデータの管理をサポートします。ただし、料金は高くなりますが、大学生は 1 年間有効な erwin Data Modeler Academic Edition を申請できます。公式 Web サイトにアクセスして、具体的な機能や使用方法を理解するためのドキュメントをダウンロードできます。
中国の公式 Web サイト: http://www.erwinchina.com/

2. Navicat
Navicat は、一般的に使用される DBMS のほぼすべてをサポートし、概念モデル、論理モデル、物理モデルをサポートし、モデル ファイルに基づいてあらゆる DBMS のスクリプトを生成できます。フォワード エンジニアリングとリバース エンジニアリングをサポートします。
ソフトウェアも無料です。
Navicat は、多くのユーザーを持つ DBMS クライアント管理ツールでもあります。
中国公式サイト: https:
//www.navicat.com.cn/

3.Microsoft Visio

現在、Visio は Office から分離されており、別途購入する必要があります。Chen の ER 図とクロウズフットをサポートします。概念モデル、論理モデルなどの表現に使用できます。

4.Draw.io は
入手が最も簡単なモデリング ツールです。Web ブラウザのアドレス バーに URL を入力するだけで呼び出せます:
draw.io
または:
https://app.diagrams.net/
前者を入力してくださいすると自動的に後者にジャンプします。
概念モデルや論理モデルの構築に適しています。Chen の ER 図と Crow's feet の ER 図の両方がサポートされています。ただし、特定の DBMS と接続することはできず、フォワード エンジニアリングおよびリバース エンジニアリングはサポートされていません。

5. MySQL Workbench は、
MySQL Community Edition に付属する無料のツールです。これは、比較的使いやすいグラフィカル インターフェイスのクライアント管理ツールでもあります。順方向ツールと逆方向ツールをサポートします。
取扱説明書は公式サイトからダウンロードできます。

プログラミング要件


https://gitee.com/kylin8575543/db2022-springにアクセスして
トレーニングに必要なデータ パッケージをダウンロードするか、このファイルをダウンロードします:
https://gitee.com/kylin8575543/db2022-spring/raw/master/rbac。 mwb

これは構築されたモデル ファイル rbac.mwb です。SQL スクリプトを自動的にエクスポートするには、MySQL Workbench モデリング モジュールのフォワード エンジニアリング機能を使用してください。

フォワードエンジニアリング

オフライン処理後、スクリプトをコードファイルに貼り付けてください。

試験指導

プロファイラーはコード ファイルを実行し、すべてのデータベース オブジェクトが期待どおりであることを確認します。Workbench によってエクスポートされたスクリプトを変更する必要はありません。


ミッションを始めましょう。成功を祈っています!

コードリファレンス

 # 请将利用MySQL Workbench软件的Modeling工具,经forward engineering 导出的创建schema的SQL语句完整粘到此处:
 
SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0; 
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0; 
SET @OLD_SQL_MODE=@@SQL_MODE, 
SQL_MODE='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';
 
CREATE SCHEMA IF NOT EXISTS rbac DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci ; 
USE rbac ;
 
 
CREATE TABLE IF NOT EXISTS rbac . aprole (
RoleNo INT NOT NULL COMMENT '角色编号', 
RoleName CHAR(20) NOT NULL COMMENT '角色名', 
Comment VARCHAR(50) NULL DEFAULT NULL COMMENT '角色描述', 
Status SMALLINT NULL DEFAULT NULL COMMENT '角色状态', 
PRIMARY KEY ( RoleNo )) 
ENGINE = InnoDB 
DEFAULT CHARACTER SET = utf8mb4 
COLLATE = utf8mb4_0900_ai_ci 
COMMENT = '角色表';
 
CREATE TABLE IF NOT EXISTS rbac . apuser(
    UserID CHAR(8) NOT NULL COMMENT '用户工号',
    UserName CHAR(8) NULL DEFAULT NULL COMMENT '用户姓名', 
    Comment VARCHAR(50) NULL DEFAULT NULL COMMENT '用户描述', 
    PassWord CHAR(32) NULL DEFAULT NULL COMMENT '口令', 
    Status SMALLINT NULL DEFAULT NULL COMMENT '状态',
    PRIMARY KEY ( UserID ), 
    UNIQUE INDEX ind_username ( UserName ASC) VISIBLE) 
    ENGINE = InnoDB 
    DEFAULT CHARACTER SET = utf8mb4
    COLLATE = utf8mb4_0900_ai_ci 
    COMMENT = '用户表';
 
CREATE TABLE IF NOT EXISTS rbac . apgroup (
    UserID CHAR(8) NOT NULL COMMENT '用户编号', 
    RoleNo INT NOT NULL COMMENT '角色编号', 
    PRIMARY KEY ( UserID , RoleNo ), 
    INDEX FK_apGroup_apRole ( RoleNo ASC) VISIBLE, 
    CONSTRAINT FK_apGroup_apRole FOREIGN KEY ( RoleNo ) REFERENCES rbac . aprole ( RoleNo ),
    CONSTRAINT FK_apGroup_apUser FOREIGN KEY ( UserID ) REFERENCES rbac . apuser ( UserID ))
    ENGINE = InnoDB 
    DEFAULT CHARACTER SET = utf8mb4 
    COLLATE = utf8mb4_0900_ai_ci 
    COMMENT = '角色分配表';
 
CREATE TABLE IF NOT EXISTS rbac . apmodule (
    ModNo BIGINT NOT NULL COMMENT '模块编号', 
    ModID CHAR(10) NULL DEFAULT NULL COMMENT '系统或模块的代码', 
    ModName CHAR(20) NULL DEFAULT NULL COMMENT '系统或模块的名称', PRIMARY KEY ( ModNo ))
    ENGINE = InnoDB 
    DEFAULT CHARACTER SET = utf8mb4 
    COLLATE = utf8mb4_0900_ai_ci 
    COMMENT = '功能模块登记表';
 
CREATE TABLE IF NOT EXISTS rbac . apright (
RoleNo INT NOT NULL COMMENT '角色编号', 
ModNo BIGINT NOT NULL COMMENT '模块编号', 
PRIMARY KEY ( RoleNo , ModNo ), 
INDEX FK_apRight_apModule ( ModNo ASC) VISIBLE,
CONSTRAINT FK_apRight_apModule 
FOREIGN KEY ( ModNo ) 
REFERENCES rbac . apmodule ( ModNo ), 
CONSTRAINT FK_apRight_apRole
FOREIGN KEY ( RoleNo ) 
REFERENCES rbac . aprole ( RoleNo ))
ENGINE = InnoDB 
DEFAULT CHARACTER SET = utf8mb4 
COLLATE = utf8mb4_0900_ai_ci 
COMMENT = '角色权限表';
 
SET SQL_MODE=@OLD_SQL_MODE; 
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS; 
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

おすすめ

転載: blog.csdn.net/qq_46373141/article/details/130745049