チーム：ジャガイモの良いフライ
メンバー：橋Xiangshuo Dangao飛ヤンHuihui梁Jiahaoパンジンゆいます
仕上げ：橋Xiangshuo
PM橋Xiangshuo：
午後05時30分10月25日14:30、午後05時30分10月27日14:30、17:30 11月1日14:30、9時間後、我々は一つしかない - デザインデータベース。
データベースの設計を開始する前に、私たちのチームメンバーはシンプルなコンセプトを実施してきた、本名チャン・リャンJiahaoポイント同級生、彼が直接私たちのための一般的な方向性を提供し、文書に設計された私のデータベースを置きます。私はまた、10月25日の会議以下は内容を記録した、議論の中に記録を作りました。
データベース設計の会議記録
全体的に、私は繰り返し3回のように設計された私たちのプロジェクトのデータベースは、各ステップは、その後、一時的な「慎重に検討」を通じて、プロジェクトのインストラクターチョウ、データベース設計インストラクター殷の先生、クラスディスカッションガイドを得るために幸運を十分に進めると思います李先生の先生の指導、私たちは私たちは完璧に向かって移動するように、さらにデータベース設計、データベース設計の進歩を促進するとして、思考の限界を認識させます。
プロトタイププロジェクトは、ほとんどのプロジェクトでは、データベースの設計は、ワークロードの多くを思われない、形状の需要を取った、完成されています。データベース設計の開始が間違っていることが証明する前に私の考えでは、我々はまた、データベース設計の激しい議論されているフィールドフリー設計データベースが反映されていない一方で、データベースの設計が困難に影響を与える大幅に実現されることを実現するために来ます5秒ごとにサーバーにデータをアップロードするために一度詳細は、私たちは「携帯電話側のノイズに洗練から「携帯電話の終わりには、サーバノイズにデータをアップロードする」必要があり、データは、これらの5秒の最大値、最小のノイズ、および平均のアップロードを記録する必要があります時間は、アップローダー、およびアップロードの位置情報は、何らかの方法」に記録する必要があり、各フィールドは簡単ではありません決定します。
いくつかの一見単純なデータベーステーブルのデザインも「自分の意見を表明 - 違いがある - と主張 - 合意に達するために、」後工程。私は深く感銘を受け、テーブル領域が下に表示されました：
地域表
我々は、プログラムが湖南大学、湖南大学の様々なランドマークの緯度経度範囲に基づいて使用し、複数のゾーンに分割され、アップロード先のノイズデータが分類されます。私たちがそのように、もともと想定されていません。しかし - それは明確である、ノイズデータフィールドとして直接緯度と経度の実装が簡単、および位置情報に対応する直接記録ノイズデータは、困難なデータベース設計を減らすことができますが、我々は考慮に雑音データを取って、多くの議論を経ていページを直接詳細な緯度と経度を提供表示されている場合、それはそうないこのプログラムを失ったが、予約された緯度および経度情報の場合には、概念の下に示された領域の導入、非常に直感的でないであろう。
データベース領域の設計の概念を導入
ユーザアバター情報を扱うには、私が確立ヘッドテーブルは、画像を選択する枚数を与える提案し、ユーザーが1つだけ選択することができます。この1つはアバターの管理がより簡単かつ効率的に行うことが、実装が簡単であることができ、我々は、各ユーザ定義および変更して再検索ヘッドテーブルへの追加や削除に対応し、用のストレージのアバターを考慮する必要はありません。それが唯一のテーブルへの外部キーまたは固定テーブルが必要です。
ヘッドテーブル
多くの類似した設計の詳細があります。それは「スペアなしの痛み」我々は、データベースの設計を改善し続けるの過程で「自分の意見を表明」でお互いをよく補完し、それが私たちのプロジェクトの開発のための良好な基礎を築いたチームのメンバーです。ケースをしようとしたときに革命が成功しなかった、道は同じでした。
ダンGaofei：
データベース設計では、我々は何度も私達のデータベース設計、コミュニケーションを教えるための責任週間と講師の先生、殷の教師を持って、例えば、テーブルの構造は、ニーズのために行って、論理的である必要があり、私たちの貴重なアドバイスをたくさん与えました表のデザインはポイントが実際に実現可能かつ効果的であるかどうかを検討する必要があります。また、主に当社のデータベース設計の設計の進歩と改善を推進します。
データベースの設計は、直接操作の難易度に影響するので、我々は、設計時に慎重な審議がされているので、データのページを表示します。
ユーザテーブルと雑音データ
ノイズデータテーブルを格納している当社のコア・システム、のために、我々はその憲法を検討するために多くの時間を費やし、非常に慎重です。地図表示や曲線の生成を考えると、我々は、データテーブルへのノイズの元データとなり、各5S記録ノイズ情報、レコードをアップロードするには、アカウントに変更して再検索ユーザーへの追加や削除を取って、我々はレコードをアップロードするためにテーブルを設計し、考慮にアイデンティティ・マップを取ります計算の膨大な量は、我々は動作速度を向上させるために特定し、地図データを格納する方法を取るために、リアルタイムで更新されないことを決定した......
それは、我々が記録された情報をアップロードするユーザーを議論する際に、このデータの議論において考慮さものの、大きな役割をされていない、私は最大値、最小値を提案し、平均値は、録音に直接格納されていると言及する価値がある、することができません特定のシナリオのための具体的な情報を反映し、あなたがこのテーブルを削除したいのですが、分析した後、携帯電話ユーザーの需要を発見し、このデータが最も有用かつ最も直感的かもしれません。この点をつかむ、我々は、このセクションのデータベースの設計を完了し、次の表の構造を完成しました。
レコードのテーブルをアップロードするユーザー
最終的に、我々はデータベースの設計上で取るアプローチは、次のとおりです。
それは、レンダリングする必要があるもののデータ：ページの思考のために？どのようなデータはデータベースに格納する必要がありますか？ページとデータベース間の論理演算は単純明快ですか？
データ型とフィールドの設定テーブルにこれに基づき、追加または削除。
非常に多くの議論がしなくなり、リストにそれらがここにあります。
これらの論理的かつ合理的なの思考によって、我々は議論では、自分の思考の厳しさを改善したが、自分の意見を明確に表現することにする当社の能力を強化しています！私は現在で収穫を得るであろうと、この経験をチームプロジェクト、将来の給付と考えています。
ヤンHuihui：
当社のデータベースには、特定のプロセスにラフから、単純なものから複雑なものまでデザインです。
私たちは、このデータベース設計プロセス内のすべての初心者であるため、我々は究極のは基本的に時間が落ち着くか、データベースが変更され、このようなフィールドの数を増やすとして、あるいはいくつかのフィールドを削除しても、変更前と変更後に何度も議論しました私たちのニーズに対応します。
初期設計に先立ち、それはテーブルの上に私たちのグループ梁Jiahaoほしいですのいくつかの追加と削除に基づいて、議論することです。
初期のデータベース設計のアイデア
この絵を基に、我々は最終的に私たちに必要なデータベーステーブルとフィールドを設定し、4時間以上に白熱した議論をアップしました。その時、私たちは、Excelの表は、この手順を完了するには、共有されて編集します。このように。ノイズデータテーブルのその時、私たちは、特にノイズデータテーブルのレコードとアップロードのテーブルのために、いくつかの回のラウンドで対立します。最後に、我々は理由が前方に置くために、これらのフィールドを完了するために決定され、様々な条件を統合しました。
データベース設計（EXCEL表現）
これらのテーブルを完了すると、私たちは私たちに助言を与えることを先生に尋ねた、データベース設計陰の先生に相談に行きました。我々は完全にテーブル間の関係を反映するために失敗エクセルでのツールを使用していない、と私たちは今、良いのPowerDesignerをダウンロードしていることを最初に陰の先生、このツールは、設計のこの段階に最適です。また、陰の先生と私たちは、データベースの設計が完了したかを決定する方法を、と言う、それはプロトタイプのインタフェースに基づいており、このインタフェースに必要なデータを見てみると、データベースから除去することができます。それらのすべてのアウトの場合、バックは効率を改善するかどうか、どのように考えるのが妥当であることを、データベースの整合性が保証されます。だから、先生殷の提案で、私たちは設計内容を表現するために、簡単な図面を作成PowerDesignerの。
データベース設計（CDM表現）
このインタフェースに基づき、我々は今、究極のバージョンを確認するためにファンクションポイントに応じて、改善を続けてきた議論に基づきます。
グループメンバーは一緒にデータベース設計を完了するために
データベースの設計は、私たちが、一緒に、一緒に研究を議論する過程で、我々は多くのことを学ぶことができるようになり、修正される必要があるかを決定することを、特に初心者のために、1回の作業を行うことができません。
梁Jiahao：
グループは、プロジェクトデータベースを設計し始めた前に、私は全体のプロジェクトチームと前回の会議の自分の理解に応じた内容の一般的なテーブルうち最初の並べ替えや、プロジェクト全体のデータベースフィールドの内容を説明します。データベースを構築するために、事前にこのような考えの後、特定の設計を完了し、次のデータベースは比較的スムーズになります完璧です。しかし、私の予想外にそれは私が唯一のいくつかのための参照の枠組みを持っているということです、そして継続的な改善と、データベースの変更のための継続的な需要の過程では、データベースには、ニーズに合わせて調整され続けています。最も時間を要しており、最大の変化は、我々のデータの中核である - ノイズデータが格納されています。
電話機がデータベースにアップロードされ第二の記憶時間のノイズを、記録しているときに、データベースの私の最も原始的な構造では、私はアイデアの前任者、デシベルデータを参照しています。会議の過程で、データベースの設計に起因するので、フィールドの具体的な内容の一切の深い議論が存在しないため、データベースのフィールドの表示にExcelを使用して、多くの経験を持っていません。
データベーステーブルの表現ECEL
我々はオンデマンドでデータベースを実装する深さで探検したかった次回の会議では、あいまいさの多くのテーブルの時間雑音データを記録し、発見しました。これは、実際の時間やモーメントの期間を指し？瞬間に言及すると、クエリ内のユーザデータは、我々はそれ秒あたりのデータをアップロードするユーザーの表示をユーザーに与えるか、自分の記録時間をアップロード？時間の期間を意味する場合、データの柔軟性が大幅に阻害されるであろう。我々は深くこの点を理解し、問題を吹く、データベース設計は、特殊なツールを使用する必要があり、このようなPowerDesignerのように、。
将来のニーズに合わないデータベースで見つかった、我々はノイズデータを保存する方法を再考開始する必要があります。ユーザーがクエリのアップロードレコードを持つことができるようにすることです、我々は1つの極端およびデータ記録処理の平均値でレコードをアップロードするユーザーを格納するテーブルを追加することを決定した後、テーブルの役割は午後のみで議論した後、良好な表示は、より多くのデータの正確さを反映しています。これまでのところ私は、理解してデータベースの設計で、時には私たちは、必要な需要の元の例を追加する必要はありません。
アップロード記録シート
しかし、それがすべてではありません。私たちは、もともと、記録中のユーザーの携帯電話に保存されたデータのみ、ユーザが録画を停止した後、携帯電話からデータベースにアップロードのみ対応するデータを想定しました。問題のようですが、私たちは何回も説明したように、ユーザがプログラムを置くならば、徐々に、簡単な例を挙げて、それは無理見つかりませんでした、冒頭にアイデアは関係なく、彼の、中断された舞台裏の録音と録画されていません最終的にデータベースにアップロードされていませんどのくらいのデータを記録します。我々は録音中に5秒ごとにアップロードされたノイズデータを行うために変更する必要がありますので、記録アップロードされたデータのアップロードデータの終了後に記録アップロードします。したがって、我々は、最も原始的なノイズデータテーブルを変更しました。私も知っているこの時点で、我々は時々 、データベースの設計における技術の実装の変化に基づいてデータベースに変更を加えます。
ノイズデータシート
我々は変更の数を行ってきた、単純なノイズデータストレージの問題、目に見えるデータベース設計は、特定のプロジェクトのさまざまな側面の変化とUH調整を追跡する必要があります。データベース設計の経験も、私は貴重な経験の多くを取得してみましょう。
パンジンゆう：
データベースを設計した後、多くのことを学びました：
まず、データベースの設計がしっかりとあなたは十分に確立需要を持つようにしたいデータベースの設計前に、需要にバインドされている、良いデザインへのデータベースのニーズを理解するために説明します。
多くの関係や、多くの関係とに関連した属性を追加する必要がある場合の関係は一から一であればCDM PDMのための回転力デザイナーを使用して、設計テーブルの外部キーの関係で使用することができます第二に、記録の関連付けを設計することができます。
以下の2つの図は：多くの関係に多くあり、従って、そのような関連付けを使用するプロパティを追加する必要はPDM自動転送機能の後に使用され、自動的にテーブルを生成することができます。
エンティティテーブルとテーブル
第三に、データベースの設計には、テーブルの主キー異なる状況のために主キーを保持することも重要であるように、このようなヘッドテーブルとして、変更されませんテーブルの基本として近づい異なるデザインを持つテーブルを作成するときに、テーブルには、対応する領域になりますデータのインポート、およびこの時間を使用するには、実質的に自己増力int型などの論理主キーを変更しない、外部キーが使用されているように、良い選択で非常に簡単にもある。しかし、ユーザーテーブルのために、どのテーブルには、これらを使用してリアルタイムで更新されます主キーの種類は、ユーザーがアカウントを主キーとして設定されている場合は、1つは、あなたが主キーインデックスに目を通すことができ、重複したアカウントに一致したときを知るために、テーブル内のデータに登録するかどうかを判断するために起こっている、ユーザーを登録するには、例えば、適切ではありませんそれが繰り返されているかどうかを知るために、この例から、私たちは基本的に同じテーブルのテーブルが必要真の変化のための論理的な主キー主キーを設計するとき、私たちはより良い自然キーを選択し使用することができることを見ることができます。
第四には、フィールドの種類を慎重に考慮されるべき文字の長さのために、テーブルを設計する際について慎重に考えなければならない、と慎重に10進浮動小数点型を考慮すべきです。
第五に、より重要な点は、問題の職務と範囲をクリアするには、そのデータベースにのみデータベースを理解することで、彼は万能薬ではありませんが、倉庫に格納データにある論理データベース設計のためには複雑すぎる、それはあります完了するまでに完了し、より大規模なコードを使用するデータベースを使用しないでください。