データベース設計者になることを学ぶのにかかる時間に圧倒されていると感じますか？必要な基本的なスキルと才能について読んでください-それほどひどいことではありません！
スーパーマーケットの通路を歩き、一方の手でショッピングカートを、もう一方の手で食料品のリストを歩いているとき、あなたは何を考えていますか？あなたが私のようなら、あなたはあなたの毎週の買い物がより少ない時間で済むように棚の組織を改善する方法を想像しています。あるいは、友人が雑誌の膨大なコレクションを見せてくれたときに、情報を整理して構成したいという同じ願望を感じるかもしれません。または、プレイリストを自分の好みに合わせて管理しているときに発生する可能性があります。エンティティ、属性、関係の観点から現実を表現する方法を考えて人生を歩むなら、あなたの使命はデータベースモデラーになることです。
それほど極端ではないかもしれませんが、それでもデータベース設計をキャリアとして追求するという考えに惹かれています。いずれにせよ、あなたはいくつかの新しいスキルを習得する必要があります。それらのいくつかは純粋に技術的なものです。これらのスキルは、勉強したり読んだりすることで学び、仕事の経験を通して深めることができます。他のスキルには、コース、ブログ記事、または他の人を観察することによって学ぶことができる非技術的な知識が含まれます。
これは、すべてのデータベース設計者が持つ必要のある基本的な知識とスキルの要約です。
データベース設計者が必要とするハードスキル
ハードスキルとは、学習を通じて習得し、実践を通じて磨きをかけるスキルです。ハードスキルを習得したことを具体的な証拠で示すことができれば、それを伴うあらゆるタスクを実行できることを意味します。
データベースの知識に関しては、ハードスキルには、データベース理論の基礎と、具体的な問題を解決するために理論的概念を適用するために使用されるさまざまな手法が含まれます。データベース設計者が必要とするそれぞれの難しいスキルを見てみましょう。
データベース理論
データベース理論には抽象的な概念がたくさんあり、実際の事実に関連付けられていないと理解するのが難しい場合があります。リレーショナルモデル、ドメイン、属性、関係と関係、主キーと外部キー、エンティティの整合性、参照整合性、およびドメインの制約はほんの一例です。さらに複雑な問題（関係代数や関係論理など）を追加すると、ガーデニングやグルメ料理などの具体的なことを扱うキャリアを選ぶのがよいのではないかと思うかもしれません。
パニックにならない。大学の授業を教えたり、情報を整理する新しい方法を発明したりする場合は、データベース理論に関する十分な知識が重要です。しかし、データベースを設計するには、実際の問題の解決に適用される理論の概念を習得するだけで済みます。最も重要なもの–データベース設計のABC –はリレーショナルモデルです。
リレーショナルモデル
大学の教授は、リレーショナルモデルは集合論と述語論理に基づくデータ編成メカニズムであるとあなたに言うでしょう。しかし、それではデータベースモデラーとしての日常業務にはあまり効果がありません。実際には、リレーショナルモデルは、データをテーブル形式で整理するための直感的でわかりやすい方法であることを知っておく必要があります。 –リレーションと呼ばれます–行で構成されます（タプルとも呼ばれます）。各テーブル（またはリレーション）は、その属性（または列）によって定義されます。
リレーショナルモデルの基本的な概念。
すべてのリレーションには、各タプルの一意の識別子を表す1つ以上の未解決の属性が必要です。データベーススラングでは、それがテーブルの鍵です。非キー属性は、各キー値が各属性の単一の可能な値を決定するという意味で、キーに依存します。
キーがナンバープレートである車両情報の表を想像してみてください。ドメインのルールにより、2台の異なる車両が同じナンバープレートを共有することは禁止されているため、ナンバープレートは各車両の属性（メーカー、モデル、所有者など）を決定します。
リレーショナルデータベース
リレーショナルデータベース管理システム（RDBMS）は、その原則を尊重して、リレーショナルモデルを実装します。これらは、クエリを通じて情報を取得し、トランザクションを通じて情報を更新する方法を提供します。リレーショナルデータベースの情報が実際の事実や状況を反映するようにするには、データベースが適用されるドメインに固有の条件または制約を定義できます。たとえば、学校の生徒に関する情報を格納するテーブルでは、生年月日が将来の日付や過去の日付を許可しないように制約を課すことができます。
データベース内のテーブルの編成は、一般にデータベーススキーマと呼ばれます。テーブルに加えて、スキーマはリレーションシップと呼ばれるテーブルのペアを含む制約を詳しく説明します。リレーションシップは、一方のテーブルのフィールドの値がもう一方のテーブルの主キーの値に対応するという制約を課すことにより、2つのテーブルを接続します。
データベーススキーマは通常、データベース設計者に共通のツールである実体関連図（ERD）で表されます。
顧客データモデルを表すERD。
異常と正規化
これまでに説明したすべての概念はかなり明確ですよね？これで、設計の欠陥または不適切なためにデータベースで発生する異常について話すことができます（つまり、データベースは、表現しようとしている現実を適切に反映していません）。
異常は、挿入、更新、または削除操作によってデータに不整合が発生した場合に発生します。たとえば、売上データを格納するテーブルがあるとします。販売ごとに（つまり、テーブルの各レコードに）、顧客の名前と住所が記録されます。異常は次のとおりです。
- 販売の1つで顧客の住所が変更された場合、および
- 同じ顧客が他の売り上げを持っている
- 他の販売の住所は古くなっています。
異常を回避するために、データベースの正規化と呼ばれる設計手法を適用できます。これには、次のような設計上の欠陥を回避するために、テーブルと列を分解する（つまり、それらを小さな部分に分割する）ことが含まれます。
- 複数の情報（アイテムのID番号や名前など）を保持する列。
- 同じ情報を同じテーブルに複数回保存する。
- 他の非キーフィールドに依存するフィールド。
非正規化テーブル（左）と正規化スキーマ（右）。
データウェアハウスと非正規化
一部のデータベースは、オンライントランザクション処理（OLTP）の代わりに、大量の情報を照会するために使用されます。これらのデータベースはデータウェアハウスと呼ばれます。
データウェアハウス内の情報は、ユーザーインターフェイスからは取得されません（たとえば、eコマース注文システムから直接入力されます）。これは、さまざまなソースから情報を収集し、処理し、クリーンアップして、テーブルに格納するバッチプロセスに由来します。このため、データウェアハウスは従来のデータベースと同じ異常にさらされていないと想定できます。
そのため、データウェアハウスはOLTPデータベースと同じ正規化条件を維持する必要はありません。一方、データウェアハウスのクエリ効率を最適化することがより重要です。これが、データウェアハウスで非正規化が適用される理由です。この手法では、ある程度の冗長性を使用してクエリを簡素化し、テーブルの数が多すぎるスキーマが乱雑にならないようにします。
典型的なデータウェアハウススキーマ。
ビッグデータ
データウェアハウジングと同様に、ビッグデータの概念は大量のデータを格納するリポジトリを指します。ただし、2つの概念には重要な違いがあります。データウェアハウスは特定の目的のために設計されており、動作と形式が事前にわかっているレポートを生成することを目的としています。
一方、ビッグデータは、さまざまなソースから高速で生成された大量のデータを収集することを目的としています。ソーシャルメディア、マイクロトランザクション、またはスマートセンサーからの情報。この膨大な量の情報は、探索や分析、または機械学習モデルのトレーニングに使用できます。
ビッグデータデータベースの設計では、並列処理とリアルタイムのデータキャプチャを可能にするために、ストレージスペースの節約とデータの分割（とりわけ）が優先されます。さらに、非リレーショナルまたはNoSQLデータベースシステムが使用されており、非構造化情報を処理するためのより優れた代替手段を提供します。
NoSQLなどのテクノロジーやビッグデータ自体の概念は、すでに40年以上前のリレーショナルデータベースと比較して比較的新しいものです。そのため、データベース設計者は、この分野の新しい開発に注意を払う必要があります。ビッグデータも大きなビジネスであることに注意してください。多くの企業がその中で主導的な地位を占めたいと考えており、そのための新しいツールやテクノロジーを開発しています。
データベース管理
データベースが稼働すると、誰かがその日常の管理を行う必要があります。これは、データベースがそれを使用するアプリケーションのボトルネックにならないように、日常的なタスクを実行することを意味します。管理タスクには、バックアップの維持、ストレージスペースの消費の監視、プロセス間のクラッシュの検出、アプリケーションの通常の動作を妨げるデータの問題の修正が含まれます。
これらのタスクを処理するデータベーススキルを持っているのは、データベース管理者、またはDBA（存在する場合）です。非常に小規模な組織、またはデータベースの操作がビジネスにとって重要ではない開発環境では、データベースの保守の責任はデータベースモデラーにある場合があります。したがって、特定の状況でDBAから引き継ぐことができる知識が必要です。ただし、いかなる状況においても、ビジネスまたはミッションクリティカルなアプリケーションをサポートする本番環境でデータベースを管理する責任を負わないでください。 。
管理タスクは、データベースシステムとそれがマウントされているインフラストラクチャによって大きく異なります。たとえば、Microsoft SQL Serverデータベースを管理するタスクは、MySQLまたはOracleデータベースを管理するタスクとは大きく異なります。また、ノートブックでローカルに実行しているサーバーの管理は、クラウドで実行しているサーバーの管理とは大きく異なります。
キャリアを通じて非常に異なるデータベースと環境を扱うことになるため、特定のデータベースサーバーの管理方法を学ぶことに多大な労力を費やすことはお勧めしません。 1つだけに特化するのはあまり良いことではありません。
並行性とトランザクション管理
データベースへの同時アクセスは、複数のユーザーが同時に同じリソースにアクセスしようとすると、アプリケーションで問題を引き起こす可能性があります。設計者として、これは私たちのビジネスではなく、これらの問題に対処するのはDBAの責任であると考えるかもしれません。また、それを可能にするアプリケーションを作成するのはプログラマーの責任だと思うかもしれません。
ただし、設計者は、同時実行の問題を回避するスキームを設計することにより、潜在的な同時実行の問題を最小限に抑えるために自分の役割を果たすことができます。
長くて複雑なトランザクションがデータベースで実行されると、多くの同時実行の問題が発生します。トランザクションが処理されている間、関連するテーブルは、情報の読み取りまたは書き込みを必要とする他のプロセスのためにブロックされます。この種の問題を回避するためにできる最善のことは、設計が少なくとも第3正規形に準拠していることを確認することです。次に、デッドロックを回避するためにトランザクションを正しく検討するのはプログラマーの責任になります。
ただし、スキーマを分割したり、それぞれが果たす機能に応じてテーブルをグループ化したりするなど、同時実行を回避する戦略を使用することもできます。
eコマースサイトのデータベースを想像してみましょう。製品、在庫、価格のマスターデータテーブルを1つのスキーマに配置し、注文と販売を別のスキーマに配置して、最初のスキーマのテーブルのビューまたは読み取り専用レプリカを配置することができます。これにより、マスターデータを更新するトランザクションを実行する際のエラーを回避できます。
データベース設計ツール
リレーショナルモデル、実体関連図、および正規化手法を理解していれば、鉛筆と紙以外のツールを使用せずにデータベースを設計できます。ただし、インテリジェントツール、特にダイアグラム内のオブジェクトの再配置や変更、設計エラーの検出、データベースを作成または更新するためのSQLスクリプトの生成、リバースエンジニアリングなどの特定の設計タスクを自動化できるツールを使用すると、パフォーマンスが大幅に向上します。既存のデータベース設計のエンジニアリング。
Vertabeloプラットフォームなどの専用ツールを習得すると、作業が大幅に高速化されます。そして、それはあなたがこの助けを持っていない他のデザイナーから目立つことを可能にするでしょう。
SQLとプログラミング
私たちは皆、「ここでの私の仕事は終わった」と誇らしげに言って、当然の休暇に向けて出発するデータベース設計を提供できるようにしたいと思っています。しかし、通常、その理想的な状況は決して起こりません。設計が完了したら、アプリケーションプログラマーはそれを使用する必要があり、彼らは彼らを助けるためにあなたを連れて行く必要があります。
開発プロジェクトを引き続き支援する必要がある1つの方法は、特定のアプリケーションのニーズを解決するために、SQL（Structured Query Language）でビュー、トリガー、ストアドプロシージャなどを作成することです。もう1つの方法は、オブジェクトリレーショナルマッピング（ORM）と呼ばれるものを使用して実行されるプログラミングタスクを監視することです。
ORMは、特定のRDBMSからのデータアクセスを抽象化することを目的としています。これの良い面は、プログラマーが使用するデータベースの詳細について心配する必要がないことです。つまり、RDBMSがMySQL、Oracle、IBM DB2、MSSQLServerであるかどうかを気にする必要がありません。 、または他の何か。
ORMの欠点は、データベース設計オブジェクト（テーブル、属性、および関係）が、Java、Python、R、またはC＃などの高級プログラミング言語のコードで定義されていることです。言い換えれば、データベース設計者がそれらを見ることができない場所です。
この問題の解決策は、アジャイル開発の方法論とその協調的な哲学にあります。これらは、プロジェクトの過程でデザイナーとプログラマーが協力することを促進するため、プログラマーとの良好な関係を維持する必要があります。あなたはそれらの隣に座って、プログラミングコードを見て、データオブジェクトの定義を共同で書くことをいとわないはずです。
ソフトスキルデータベース設計者が持つべきもの
データベース設計に固有の理論的および技術的知識に加えて、設計者は理想的には「ソフトスキル」と呼ばれる他のスキルを持っている必要があります。これらのスキルは、優れたコミュニケーターであり、最終製品に対するビジネスのビジョンを理解するなど、間接的に仕事の成功に影響を与えます。以下で説明するのはほんの一例ですが、潜在的な雇用主から非常に高く評価されているソフトスキルは他にもたくさんあります。
ビジネスビジョン
データベースを設計するときは、相互に関連するデータオブジェクトの観点からビジネスの現実を表現しています。設計は標準化の条件を満たす必要があり、不整合、異常、同時実行の問題を回避する必要があることがわかりました。しかし、同じように重要なのは、あるいはもっと重要なことですが、デザインが、給与を支払っている人のビジネスビジョンと一致していることです。
ビジネスビジョンを理解することで、各要件の重要性をよりよく把握し、意思決定を導き、設計が組織の目的によりよく一致するようになります。
これは、ビジネスビジョンを理解することがあなたの仕事をどのように形作るかについての簡単な例です。テーブルで代理キーを使用すると、デザインが乱雑になり、不要で煩わしい要素が追加されると思うかもしれません。ただし、サロゲートキーを省略すると、INTEGERタイプのキーで優れたパフォーマンスが得られる可能性があるため、そのテーブルでのクエリが遅くなる可能性があります。ビジネスビジョンが高速クエリを提供することである場合は、代理キーが最適です。
コミュニケーションスキル
素晴らしいデザインを作るだけでは十分ではありません。また、デザインが機能する理由を説明できる必要があります。これを行う方法は、談話的（口頭または書面）と視覚の両方でそれを提示する方法を知ることです。
目立つように、デザインの長所のリストを作成します。それを作成するために行った決定について考え、それらの決定の理由を書き留めてください。あなたの決定とデザインを、それを理解していない人や変更したい人に守って、不完全または欠陥のあるものにする準備をしてください。
しかし、建設的な批判を受け入れ、自分とは異なる見方を検討することも進んで行う必要があります。プログラマーは、あなたが見なかった問題を見つけて、あなたに良いアドバイスを与えることがあります。データベースの知識がないと思って同僚を解雇しないでください。
対人スキル
プログラマーとの良好な関係を持つことの利点について、上記でコメントしました。自分の専門分野がどれほど進んでいても、設計の一部を再考する必要のある欠陥を検出したテスターであろうと、必要なプロジェクトマネージャーであろうと、すべてのチームメンバーとの友情の姿勢を維持することが重要です。あなたは特定の日付までにタスクを達成します。つまり、あなたはチームプレーヤーでなければなりません 。かけがえのないものだと感じ、ルールを課したいプリマ・ドンナスをチームに入れたいと思う人は誰もいません。
開発チームのデータベース設計者はあなただけではないかもしれません。多分あなたはあなたの同僚のサブグループを率いる必要があります。そのためには、リーダーシップスキルを示し、プロジェクトマネージャーとして行動し、データベース設計者のチームがその目的を達成し、意欲を維持できるようにする必要があります。
データベース設計スキルを学ぶ方法
大学の学位、コース、本、専門記事から、データベース設計者になるために必要なスキルを習得できます。大学のコースの利点は、必要なすべての知識を提供し、その知識を認められた程度で支持することです。欠点は、時間とお金の多大な投資を必要とすることです。
本や記事を読んで自分で学ぶことを好む場合は、時間とお金を節約できますが、重要なトピックを案内し、知識を評価するためのガイドが必要になります。また、知識をバックアップする学位がないため、実践的な方法で知識を実証する必要があります。
いずれにせよ、あなたがコースを受講することによって学ぶか読むことによって学ぶかどうかにかかわらず、その知識は基礎としてのみ役立つでしょう。モデルを作成し、実際の問題に直面し、同僚や同僚の行動を観察することで、最も多くを学ぶことができます。