タグ付けされた質問 「relational-theory」

私は自分のリーグではないデータベース設計の問題に出くわしました。そして、私の頼りになるDBAの第一人者が消防訓練に出かけています。 本質的に、私は次の主キー（簡潔にするためにPK）を持つテーブルを持っています。 child_id integer parent_id integer date datetime child_idそして、parent_idエンティティテーブルへの外部キーです。「子」テーブル自体にも「親」テーブルへの外部キーが含まれています。loはそれぞれ、child_id常にparent_id上記のテーブルで想定されているものと同じものを参照します。実際、この2つを同期させるための追加のコードがあることがわかります。 これにより、この熱狂的な正規化の初心者は「代わりに冗長性を削除する必要があります！」と言います。 私は次のように分解します。 Table_1 PK: child_id integer date datetime Table_2 PK: parent_id integer date datetime Table_3: (already exists) child_id integer PRIMARY KEY parent_id integer FOREIGN KEY そして、これらの人たちを自然な方法で結合すると、元のテーブルが回復します。この5NFを作ったのは私の理解です。 しかし、今ではビジネスルールが隠されていることに気づきました。 通常、特定child_idのに関連付けられている日付は、対応するに関連付けられている日付のサブセットである必要がありますparent_id。最初のテーブルがこのルールを適用していることがわかります。 日付が大きくなりすぎるまで自由に表1に追加できるため、私の分解ではルールを適用しません。 これは私をここに導き、次の質問があります： この分解は5NFですか？私はそれが挿入異常を許可すると言うだろうが、また次のそれ自体、Wikiの例に従うように見えるこのガイドを。「私が強調したもの」というフレーズは、「3つの別個のレコードタイプからなる正規化された形式からすべての真の事実を再構築できる」という特別な休止を与えますTable_1。 この分解が気に入らないとしましょう（気に入らない）。テーブルとコードをそのままにしておくことが実際的な解決策であることを私は自由に認めます。しかし、理論的には、最初のテーブルから離れてビジネスルールを保持するように制約を分解または追加する方法はありますか？

10 database-design  schema  normalization  relational-theory  best-practices 

講義では、講師が主キーのないテーブルを見せてくれました。質問したところ、彼は3NFで推移的な依存関係を削除するときに、主キーのないテーブルがあっても問題ないと述べました。 ただし、主キーがないということは、機能上の依存関係がないことを意味しますが、3NFは推移的な依存関係の削除であり、すべての機能上の依存関係のため、各テーブルには正規化のための主キーが必要であると教えられました。 主キーなしでテーブルを作成することは完全に可能ですが、そのテーブルが存在する場合、そのデータベースは正規化されていると見なされますか？ 追加する必要があります。テーブルには「一意のキー」、プライマリ、コンポジット、外部はありません。 表示されているテーブルには3つの属性があり、どれもプライマリまたは一意としてラベル付けされていません。私はそれが間違いかどうか尋ねました、そして彼はそれがなくても大丈夫だと言いました。この表の情報を一意に特定できないため、私はその発言に疑問を投げかけ、彼はこのようにしてよいと主張しました。これは私が正規化について教えられたことに反しています。

9 database-design  normalization  relational-theory 

第一正規形とは何かの決定版を取得しようとしています。私が読んだものはすべて、少し異なるスピンを持っています。 日付などの多くの当局は、定義によって関係は常に第1正規形であると言いますが、他の当局は要件のリストを提供します。つまり、1NFの要件は0から多くあります。 違いは、テーブルとリレーションの間の違いだと思います。テーブルは完全に混乱する可能性がありますが、リレーションシップは特定の制限に従います。したがって、リレーションがSQLでテーブルとして表されるという事実により、混乱が生じます。 SQLデータベースに関連するため、特に1NFに焦点を当てています。問題は、テーブルが最初の正規形であることを保証するために必要なプロパティは何ですか？ 多くの当局は、表が関係を表す場合、それはすでに1NFにあると示唆しています。これにより、1NFの定義が関係の定義に戻ります。 1NFのテーブルのいくつかのプロパティは次のとおりです。 列の順序は重要ではありません[1] 行の順序は重要ではありません すべての行は同じ長さです（つまり、行データは列ヘッダーと一致します） 重複行はありません（これは代理主キーを使用して保証できますが、PK自体は必要ありません） 繰り返し列はありません 各列には単一の値（アトミック）が含まれています [1]技術的には属性は順序付けされていませんが、テーブルでは、行データは列ヘッダーと同じ順序である必要があります。ただし、実際の順序は重要ではありません。 上の複数のデータ： アトミックデータの概念は、アイテムをさらに分解することはできないということです。この概念は、技術的にはすべて吐き気を分解することができますが、問題のデータは、データの使用方法によっては、実際にはそれ以上分解できないという点で評価されています。 たとえば、通常、完全な住所または完全な名前はさらに分解する必要がありますが、名前や町の名前などのコンポーネントは、文字列として使用できるという事実にもかかわらず、おそらくこれ以上分解すべきではありません。 列を繰り返すように、それが持っている貧弱な設計カラムでほぼ等列、繰り返しphone1、phone2一般に等、繰り返されるデータは、追加の関連テーブルの必要性を示しています。 依存 同じヘッダーに準拠していることを除いて、行間に関係があってはなりません。 列の間にも関係があってはなりませんが、それがより高い正規形の主題であると私は信じています。 問題は次のとおりです。1NFの定義には上記のどれくらいが含まれていますか？独立した行ビットもそれに含まれますか？

9 database-design  normalization  relational-theory 

User_FriendList次の特性を持つと呼ばれるテーブルがあるとします。 CREATE TABLE User_FriendList ( ID ..., User_ID..., FriendList_IDs..., CONSTRAINT User_Friendlist_PK PRIMARY KEY (ID) ); また、上記の表に次のデータが含まれているとします。 + ---- + --------- + --------------------------- + | ID | User_ID | Friendlist_IDs | + ---- + --------- + --------------------------- + | 1 | 102 | 2：15：66：35：26：17：| + ---- + --------- + --------------------------- + …

9 database-design  foreign-key  normalization  relational-theory 

たとえば、テーブルがあるとします。 Business(BusinessID, Lattitude, Longitude) もちろん、すべてに索引が付けられています。また、100万件のレコードがあります たとえば、106,5に最も近いビジネスを検索したい場合、どうすればよいでしょうか。 私が行った場合 SELECT * FROM Business WHERE (Some formula to compute distance here) < 2000 たとえば、または私が行う場合 SELECT * FROM Business TOP 20 理論的には、コンピューターはすべてのビジネスの距離を計算する必要がありますが、実際には、緯度と経度が特定の範囲内にあり、計算する必要があるビジネスのみが計算されます。 たとえば、PhPやSQLでやりたいことはどのようにしたらよいでしょうか。 これまでの答えに感謝しています。私はmysqlを使用していますが、それらには明らかな解決策よりも効率的なものはありません。MySQL空間には、距離計算機能もありません。

9 optimization  mysql-5.5  relational-theory  spatial 

私が理解しているように、第3正規形（3NF）は基本的に、キーが1つだけであることを意味します。 たとえば自動インクリメントid列があるテーブルに、一意であり、nullではないことがわかっている列（社会保障番号など）もある場合、この他の列をキーとして使用できます。 厳密にスキーマ設計の観点から、実用的/ビジネス上の問題（SSNをキー/ FKとして渡す場合のセキュリティ/プライバシーリスクなど）を無視すると、そのようなテーブルは実質的に2つのキーがあるため3NFに含まれませんか？ 他の列に一意のキーがあったかどうかによって、答えは異なりますか？もしそうなら、なぜですか？

8 database-design  relational-theory 

次のシナリオのデータベーススキームを作成しています。 ユーザーがいます ユーザーには役割があります（「開発者」や「CEO」など） ロールにはアプリケーションがあります（「Topdesk」など） アプリケーションには権限があります（「ナレッジベースの更新」など） ロールがアプリケーションへのアクセス権をすでに持っている場合、ロールは権限を持つことができます 高性能環境がない（速度を最適化する必要がない）と仮定すると、このスキーマを実装する最良の方法は何でしょうか？データベース環境には、MySQL、MSSQLを使用できます。リレーショナルデータベースの設計が重要です。 私自身は次のことを考え出しました： もちろん、最も不確かな部分は、Applications_Permissions_Rolesテーブルです。これは、リンクテーブルですの上に別のリンクテーブル。これまで使用したことも、見たこともありません。それを行う別の方法は、それを役割と権限の間のリンクテーブルで置き換え、次にコードまたは制約を使用して必要な関係を確認することです...しかし、それは私にとって良い解決策のようではありません。これらのことは、コードレベルではなく、可能な限り（可能であると思われる場合）データベースレベルで実施する必要があります。 次に、Permissions.ApplicationとApplications.Idの間のリンクが必要ですか？Roles_Applicationsに行がない可能性があるため（新しいアプリケーションを追加した直後など）、どの権限がどのアプリケーションに属しているかを判別することができないため、これを使用します。また、権限が属するアプリケーションを検索するための単一の参照ポイントでもあります。これは正しいと思いますが、それはまた、データベース設計において円を描くものです。ON_DELETEまたはON_UPDATEをカスケードに設定しようとすると、MSSQLエラーが発生します。 何か提案、またはこれはどのように行われることになっていますか？命名規則などに関するその他の提案も（おそらくコメントとして）歓迎されます。 ありがとう、 Luc 編集：タイトルを変更しました。以前のものはより包括的でしたが、おそらく複雑すぎます。

8 database-design  normalization  relational-theory 

私はMySQLで友情関係を築いています。友好関係は相互関係です。AがBの友達である場合、BはAの友達です。ユーザーの1人が友情を終了した場合、関係は低下します。どっちがいいのか知りたい。 実行中のシステムがあります。 user ----------- userid p.k name friends ------- userid friendid primary key (`userid`,`friendid`), key `friendid` (`friendid`) 1 2 2 5 1 3 To get all of my friends; SELECT u.name, f.friendid , IF(f.userid = $userid, f.friendid, f.userid) friendid FROM friends f inner join user u ON ( u.userid = …

8 mysql  relational-theory 

私の会社はエネルギー業界に属しており、測定単位の変換を表す良い方法を考え出す必要があります。私はいくつかの検索を行ったが、必要な深さでこれをカバーする良い記事をまだ見つけていない。ユニット変換について公開されているほとんどの情報は、ユニット1が与えられた場合、ユニット2に到達するための既知の（ハードコードされた）変換率があり、それが単純な計算であることを前提としています（これは私が見つけた中で最も複雑な例で、まだ役に立ちません）。ただし、これは現実の世界では常に当てはまるわけではなく、処理しなければならないことについても当てはまりません。（長い記事で申し訳ありません-私はできるだけ多くの情報を提供しようとしています！） トリッキーな例1： $ 5をユーロに、またはその逆に変換するなど、一部の変換は時間とともに変化します。これはエネルギーとは何の関係もないように聞こえますが、実際にはエネルギー商品市場（株式市場を考えてください）に関係しています。 トリッキーな例2：（ 過度に簡略化された）一部の天然ガスは他のものよりも熱く燃えます。さらに、天然ガスは、ガスのエネルギー（Thermsなど）またはガスの体積（MCFなどの1000立方フィート）に基づいて測定/保存でき、その他の可能性（たとえばトンのためのミサ）。ガソリンの類推は、87オクタン無鉛の1ガロンが、93オクタン無鉛の1ガロンよりも少ないエネルギーを提供することです。 トリッキーな例3： これらの測定単位があることに加えて、サームあたりの$またはMCFあたりの€などのレートも処理する必要があります。これらのレートで動作するようにいくつかの方法が必要で、どのように彼らは我々がから変換する必要がある場合に、ベースユニットに関連する我々はそうサームあたり$にMCFあたり€、我々はできるし、それからの変換と同じ公表レートを利用しサームにMCF。 トリッキーな例4： 以前は、「エネルギー」という用語を非常に緩く使用し、場合によっては誤って使用したことがあります。この時点で、そしてこれからは、状況が変わります。したがって、最後のカーブボールは、エネルギーとパワーの両方を扱うことです。電気の場合、これはkWH対kWを意味します（Yahoo Answersであるにもかかわらず、かなり良い説明です）。データの類推：ダウンロードしたデータの合計MBとMbpsを比較するようなものですISPが提供する帯域幅。データと同様に、エネルギーの供給には時間がかかります。データの類推を続けると、ある期間にわたって消費された平均有効帯域幅を計算する必要がある場合があるため、60MBが1分間にダウンロードされた場合、「有効」レートは60 * 8/60 = 8Mbpsになります。ここでの「トリック」は、Mbpsをユニットとして保存する場合、時間コンポーネントも含みますが、MBに直接関連付ける何らかの方法が必要であることです。幸いなことに、エネルギーから電力（またはその逆）への変換は、私たちが行う必要があるかなりまれなことです。そのため、私たちのソリューションは、他のすべてのトリッキーな例に合わせて最適化し、うまくいけば、この例も可能にする必要がありますが、関連する処理は行いません。エネルギー電源へのオプションです。 トリッキー例5： これは基本的に3 + 4である我々は両方持っているかもしれKWあたり$だけでなく、キロワット時あたりの$を、その速度は、両方を扱うパワーとエネルギー。 簡単な例： 一部の変換は非常に簡単で、これらはWeb上のほとんどの情報が処理できる変換です。1000 Wh = 1kWhなど。サームとデサームまたはkWからMWなどでも同じことが言えます。ここでは手助けは必要ありませんが、変換の約70％がこのタイプになることに注意してください。 開始方法についての私の考えですが、終了方法については不明です： これは明らかに非常に厄介なので、各商品と「使用タイプ」のすべてのデータを格納するために標準測定単位を選択することを提案します。したがって、電気の場合、標準のエネルギー単位はkWH、標準の電力単位はkWになります。したがって、他のエネルギー/電力単位に変換するには、すべての可能な組み合わせではなく、標準との間の変換率のみが必要です。MWからWに変換する必要がある場合は、kWへの変換またはkWからの変換によっていつでも実行できます。 変換率は特定の時間に依存する可能性があるため、この時間を測定に関連して保存できるようにする必要があります。これらのコンバージョン率が1時間に1回以上変化することを心配する必要はなく、1日1回と想定することもできると思います。 変換率は公開された値に依存する可能性があるため、この値を測定に関連して保存できるようにする必要があります。これらのコンバージョン率が1時間に1回以上変化することを心配する必要はなく、1日1回と想定することもできると思います。 これがすべて理解できたら、すべての単位変換を処理する以外に何もしないWebサービスを作成することを期待しています。私はこれらの変換を実行するSQLを探していません。それを作成するためにいくつかの創造的なキャッシュを行うことができるので、これらのテーブルを完全にハンマー処理するわけではありませんが、ユーザーがアクセスするWebサイトでページの読み込みあたり〜400の値の変換を処理する必要がある場合があります。これが重要かどうか、どのように重要かはわかりません。 変わらないコンバージョン率と変わらないコンバージョン率をどのレベルで保存すればよいかわからず、簡単に簡単にアクセスできる方法で正確にキーオフする方法もわかりませんと連携。 これに取り組む方法、または役立つ可能性のあるいくつかの公開されたリーディングマテリアルに取り組む方法についての考えは？私はSQL Serverを使用しています（間もなくSQL Azureになります）が、これは特に問題にはなりません。これを適切に表すためのスキーマが、ここで問題になっています。インチとセンチメートルのように単純なものであれば、簡単です。しかし、ここでは変換率の違いが問題です。

8 sql-server  schema  relational-theory 

私は現在、CJ Dateの「SQL and Relational Theory」を読んでいます。そして、私は本の中でかなり遠いですが、いくつかの基本的な質問があります。「論理的差異」という用語が何を意味するのか知りたいのですが、この本では例を使って用語を説明しようとしていますが、実際にはそれが何を意味するのかは説明していません（または多分それを誤解していますか？）。 これは本の一部です： 私は関係と関係の絵の間に論理的な違いがあると言いました。論理的差異の概念は、ウィトゲンシュタインの口述に由来します。 すべての論理的な違いは大きな違いです。 私は論理的な違いが直感的に何を意味するかを知っています、私は関係と関係の絵の違いが何であるかを知っています。私が求めているのは、「論理的差異」の概念を形式的に定義したものです。その意味がよくわかります。

8 relational-theory  database-design