0

RDBMS スキーマの設計において、具体的なオブジェクトの形式的な原則があるかどうか疑問に思います。たとえば、Persons テーブルの場合、各レコードは非常に具体的で一意です。実際、各レコードは一意の人物を表します。

Coursesしかし、 （学校のような）テーブルはどうでしょうか。コースの「一般的なプロパティ」である、説明、単位数、秋 (秋) または春にのみ提供されるものなどを含めることができます。

そして、月曜日、水曜日、または火/木曜日のいずれであるか (午前 10 時から午前 11 時など)CourseSessionsに関する情報time_fromとtime_to、それを教えているインストラクター、およびcourse_idコース テーブルへの a を使用して戻ってくる情報を含む actual があります。

したがって、上記の 2 つのテーブルは両方とも必要です。

「具体的」対「抽象的」のテーブル設計の原則はありますか?

更新：ここで「抽象的」とは、コースが抽象的なアイデアであることを意味します...その複数のインスタンスが存在する可能性があります...たとえば、午前10時から11時までの物理学10コースと、午後12時から午後1時までの別のコースなどです。

4

2 に答える 2

1

たとえば、Persons テーブルの場合、各レコードは非常に具体的で一意です。実際、各レコードは一意の人物を表しています。

それは希望ですが、状況の現実ではありません。

移民または法定死亡ステータスによって、同一人物を表す 2 つ (またはそれ以上) のレコードが存在する可能性があります。人を一意に識別することは困難です。姓、名、ミドルネームは一致する可能性がありますが、実際には異なる人を反映しています。SSN/SIN は変更される可能性があるため、信頼できません (移民、法的に死亡)。名前は性別を保証するものではなく、性別は変更できます。

「具体的」対「抽象的」のテーブル設計の原則はありますか

「具体的」と「抽象的」の分類は恣意的であり、解釈の対象となります。開始日と終了日は本当にコースセッションを「具体的」にしますか? [Calendaring software of choice] で多くのことを予約できるからといって、実際に授業が行われたわけでも、最終成績が正当な値であることを意味するわけでもありません...

テーブルの設計は、ビジネス ルールと、それらのルールをサポートするために必要な論理エンティティ (物理モデルのテーブルになる可能性がある) に基づいています。正規化は、これらのエンティティをより明確にするのに役立ちます。

于 2010-09-06T00:00:42.447 に答える
0

数学に基づくリレーショナル データ モデルは、特定の操作がリスクなしで正しいデータ モデルを設計する方法を証明します。

残念ながら、この種のデータ モデルは、データベースのパフォーマンスの問題に対する適切な解決策ではありません。特定のビジネス ドメインのテーブルをどのように編成するかは、オブジェクトの抽象モデルやデータベースの正規化だけでなく、システムのパフォーマンス プランニングも考慮する必要があります。はい、抽象化の漏れです。

たとえば、ツリー構造には、隣接モデルとマテリアライズド パス モデル ( The art of SQL ) の 2 つの設計戦略があります。どちらが優れているかは、どの操作を最適化する必要があるかに基づいています。

私がお勧めする優れた古典的な記事があります: The Law of Leaky Abstractions

抽象化には代償があります (そして、それは多くの場合、予想よりも高くなります)
キース・クーパー

私の意見では、SQL の芸術はもちろん、データベース設計の魂です。

于 2011-07-01T03:18:02.633 に答える