データベースに関する理解
1874 ワード
1:N,N:1及びN:M
1:N means one to many, Like an author has many books
N:1 means many to one, Like there are many line items on a single purchase order
N:M means many to many, Like a magazine company sells many different magazine title to many customers
1:N 1:Nデータベースには、2つのテーブル作成方法があります.
1)
ここではbookには作者が一人しかいないと仮定します.1以外のエンティティテーブルで1エンティティを参照します.
例:
一つの中国には24の省があり、浙江省にはxxxの市があり、この関係は明確に1)を採用しているが、1)例
中の本の作者の現実は普通いくつかあって、1つだけあるはずがないので、実体の間の関係を明確にすることが重要です.
2)
2)方式は柔軟で,1:N,N:1,N:M関係を表すことができ,欠点は連表クエリを行う必要がある.
≪マッピング・テーブル|Mapping Table|oem_src≫:マッピング・テーブル、暗黙的マッピング・テーブルの表示
例えばrestbusのscheduleは暗黙的なマッピングテーブルであり、関連ルートと車両、なぜ暗黙的なのか、
主に彼の現実には対応するエンティティ、すなわち時刻表があり、独立したエンティティと考えやすい.
以上のtb_mapABは表示して、1、マッピング関係は理解しやすくて、2、表名も取りにくいで、いっそ
ネーミングテーブルAテーブルBのマッピング.
3つの側面からテーブルフィールドの設計を考察し、***を照会し、**を修正し、*を削除する.
scheduleに運転手番号を追加するかどうかは、追加すべきではありません.車両と運転手の対応関係が変化すれば、schedule側も修正する必要があります.車両番号を通じて動的に対応運転手番号を見つけることができます.冗長性の観点から、scheduleに運転手番号を追加するのも冗長です.適切な冗長性はクエリー速度を増加させることができ、現在、こちらの表の規模は効率にあまり影響を与えず、冗長性データは一般的に変化しないでしょう.
1:N means one to many, Like an author has many books
N:1 means many to one, Like there are many line items on a single purchase order
N:M means many to many, Like a magazine company sells many different magazine title to many customers
1:N 1:Nデータベースには、2つのテーブル作成方法があります.
1)
create table tb_author {
a_id int primary key auto_increment not null,
a_name varchar(20) not null
}
create table tb_book {
b_id int primary key auto_increment not null,
b_name varchar(30) not null,
a_id int not null
}
ここではbookには作者が一人しかいないと仮定します.1以外のエンティティテーブルで1エンティティを参照します.
例:
一つの中国には24の省があり、浙江省にはxxxの市があり、この関係は明確に1)を採用しているが、1)例
中の本の作者の現実は普通いくつかあって、1つだけあるはずがないので、実体の間の関係を明確にすることが重要です.
2)
create table tb_author {
a_id int primary key auto_increment not null,
a_name varchar(20) not null
}
create table tb_book {
b_id int primary key auto_increment not null,
b_name varchar(30) not null
}
create table tb_mapAB {
a_id int not null,
b_id int not null
}
2)方式は柔軟で,1:N,N:1,N:M関係を表すことができ,欠点は連表クエリを行う必要がある.
≪マッピング・テーブル|Mapping Table|oem_src≫:マッピング・テーブル、暗黙的マッピング・テーブルの表示
例えばrestbusのscheduleは暗黙的なマッピングテーブルであり、関連ルートと車両、なぜ暗黙的なのか、
主に彼の現実には対応するエンティティ、すなわち時刻表があり、独立したエンティティと考えやすい.
以上のtb_mapABは表示して、1、マッピング関係は理解しやすくて、2、表名も取りにくいで、いっそ
ネーミングテーブルAテーブルBのマッピング.
3つの側面からテーブルフィールドの設計を考察し、***を照会し、**を修正し、*を削除する.
scheduleに運転手番号を追加するかどうかは、追加すべきではありません.車両と運転手の対応関係が変化すれば、schedule側も修正する必要があります.車両番号を通じて動的に対応運転手番号を見つけることができます.冗長性の観点から、scheduleに運転手番号を追加するのも冗長です.適切な冗長性はクエリー速度を増加させることができ、現在、こちらの表の規模は効率にあまり影響を与えず、冗長性データは一般的に変化しないでしょう.