1

DB と MySQL の設計は初めてです

簡潔にするために、私が持っている情報はAppId, Last Name, First Name, Gender, Age, DoB, Relation, School Name, School Address, School Phone Number, Teachers, Councilers, If they are in childcare 次のとおりです（AppIDは送信されているアプリケーションIDです）

基本的に、これはすべてが決定されていることを確認する方法であり、最も正規化するためにどのテーブルを作成する必要があるかを示しています

AppID -> Child ID
childID -> Last Name, FirstName, Gender, Age, DoB, Relation, School Name, Grade, Child Care
School Name -> Address School, School Phone Number, teacherID,counselorID
teacherID -> First Name, Last Name, Course
CounselorID -> First Name, Last Name, Counselor type

ただし、これを完全に正規化しようとするのが良い考えかどうかはわかりません。これは私が支援しているかなり小さなグループであり、テーブルの結合に通常のグループ化されたルックアップよりも時間がかかり、より多くのスペースを占有する可能性があるためです。

もう 1 つの懸念は、MySQL が 1 つの自動インクリメンタル変数しか許可しないことです。これは、クエリで同様のものを定義できますが、可能であれば定義する必要はありません。2 つの増分は、teacherID と CoouncelorID です。

ご意見をお待ちしております。

編集: これが基本的な構造です。また、後で変更属性を追加し、コースを削除します。ありがとうございました

   CREATE TABLE `Client_Child_Info` (
      `FirstName` varchar(15) NOT NULL,
      `LastName` varchar(15) NOT NULL,
      `Gender` tinyint(1) NOT NULL,
      `Age` tinyint(4) NOT NULL,
      `DoB` date NOT NULL,
      `Relation` varchar(15) NOT NULL,
      `Grade` varchar(3) NOT NULL default 'NA',
      `ChildCare` tinyint(1) NOT NULL default '0',
      `ChildID` int(11) NOT NULL auto_increment,
      PRIMARY KEY  (`ChildID`),
      KEY `Age` (`Age`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Basic Child Information' AUTO_INCREMENT=1 ;

    CREATE TABLE `Client_Child_Schoolinfo` (
      `SchoolID` int(11) NOT NULL,
      `SchoolName` varchar(50) NOT NULL,
      `SchoolAddress` varchar(50) default NULL,
      `SchoolPhone` varchar(15) default NULL,
      PRIMARY KEY  (`SchoolID`),
      KEY `SchoolName` (`SchoolName`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='School Information for a given ID ';

    CREATE TABLE `Client_child_teacher` (
      `TeacherID` int(11) NOT NULL,
      `FirstName` varchar(15) NOT NULL,
      `LastName` varchar(15) NOT NULL,
      `Guidance` tinyint(1) NOT NULL COMMENT 'determines if the person is a guidance councilor or teacher',
      PRIMARY KEY  (`TeacherID`),
      KEY `Guidance` (`Guidance`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Teacher information';

    CREATE TABLE `Client_RTchild` (
      `AppID` int(11) NOT NULL,
      `ChildID` int(11) NOT NULL auto_increment,
      PRIMARY KEY  (`ChildID`),
      KEY `AppID` (`AppID`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Reference Table Applicant to Client' AUTO_INCREMENT=1 ;

    CREATE TABLE `Client_RTteacher` (
      `SchoolID` int(11) NOT NULL,
      `TeacherID` int(11) NOT NULL,
      PRIMARY KEY  (`TeacherID`),
      KEY `SchoolID` (`SchoolID`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Reference Table for teacher to school ';

    CREATE TABLE `Client_RTschool` (
      `ChildID` int(11) NOT NULL,
      `SchoolID` int(11) NOT NULL auto_increment,
      PRIMARY KEY  (`SchoolID`),
      KEY `ChildID` (`ChildID`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Reference Table Child to SchoolID it is attending' AUTO_INCREMENT=1 ;

ALTER TABLE `Client_Child_Info`
  ADD CONSTRAINT `Client_Child_Info_ibfk_1` FOREIGN KEY (`ChildID`) REFERENCES `Client_RTchild` (`ChildID`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `Client_Child_Schoolinfo`
  ADD CONSTRAINT `Client_Child_Schoolinfo_ibfk_1` FOREIGN KEY (`SchoolID`) REFERENCES `Client_RTschool` (`SchoolID`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `Client_child_teacher`
  ADD CONSTRAINT `Client_child_teacher_ibfk_1` FOREIGN KEY (`TeacherID`) REFERENCES `Client_RTteacher` (`TeacherID`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `Client_RTschool`
  ADD CONSTRAINT `Client_RTschool_ibfk_1` FOREIGN KEY (`ChildID`) REFERENCES `Client_RTchild` (`ChildID`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `Client_RTteacher`
  ADD CONSTRAINT `Client_RTteacher_ibfk_1` FOREIGN KEY (`SchoolID`) REFERENCES `Client_RTschool` (`SchoolID`) ON DELETE CASCADE ON UPDATE CASCADE;
4

1 に答える 1

0

...古いものとコメントが一方向に向かっています。

ステートメントの根拠をいくつか挙げてみましょう。

テーブルのような構造化情報を共有するためのベースラインは、他のベンダーの MS Excel または Office ソフトウェアです。残念ながら、これらのクライアント アプリケーションは、複数の作成者によるほぼ同時の編集には適していませんが、1 人の作成者から複数の読み取り者に情報を配布するには十分です。したがって、作業モードが 2 番目の場合、MS Excel は文字通り常識であり、配布/トレーニングの労力が少ないため、データとデータの概念をデータベース システムに転送する努力をしても意味がありません。

ただし、複数の作成者によるほぼ同時の編集が必要で、サーバー ハードウェアとアプリケーション開発に余裕がある場合は、サーバー上のデータベースがデータの保存に最適な場所です。

さて、データベースの決定が下されたことを考えると、正規化または非正規化に進むことは設計上の決定です。メンテナンス、セットアップ作業、ハードウェア サポートなどの要因が、設計上の決定に影響を与えます。ソフトウェア機能の設計はデータモデルの設計に依存し、ソフトウェア機能の設計は、アプリケーションを処理するビジネスロジックをサポートする必要があります。残念なことに、非正規化は、多くの場合、ビジネス ロジックによると (正規化されたモデルにも適用されている基本的な仮定の上に) 仮定に基づいて構築されます。将来の開発では、それまでにソフトウェア機能も変更する必要があるという醜い結果で改訂されることがよくあります。 . そこから来る非正規化には、ソフトウェアのスコープが時間制限されていない場合、いくつかの利点があります。

于 2016-03-09T12:24:21.480 に答える