ヘアサロンデータベースプロジェクト

更新日：2018年1月22日Richard Holowczak

次の資料は、小さな美容院をサポートするデータベースアプリケーションの設計と開発を文書化したものです。プロジェクトは、ビジネスの説明から始まり、概念（E-R）モデリング、論理（リレーショナル）モデリング、物理モデリング、そして最後にデータベースアプリケーションの実装に進みます。実行されているステップのいくつかの特定の機能を説明するために、各セクションの最後にメモ（解説）が提供されています。

目次

私。ビジネスシナリオ
II。 UML表記を使用したERモデル
III。リレーショナルモデルへの変換
IV。正規化
V. SQLを使用したデータベーススキーマの作成
VI。データベースアプリケーション
VII。結論

。

私。ビジネスシナリオ

当社はマンハッタンのミッドタウンで7年間ヘア＆ネイルサロンを所有・運営してきました。スプレッドシートと紙のログブックを使用して、顧客、予定、支払いを追跡しています。この手動によるビジネス追跡方法をデータベースに置き換えたいと思います。

私たちのビジネスでは、お客様はお気に入りのヘアスタイリスト（お客様の髪をカットしてスタイリングする人々）または他の従業員とアポイントメントを取り、基本的なヘアカット/スタイリング、ヘアカラー、ハイライト、パーマ、フェイシャル、マニキュア、ペディキュアなど。材料（シャンプー、髪の色）と各サービスの完了にかかる時間を追跡する必要があります。各サービスには標準価格がありますが、プロモーションやその他の要因が、特定のサービスの顧客に提供される実際の価格に影響を与える可能性があります。

また、自宅の住所、連絡先情報、賃金率など、従業員を追跡する必要があります。各顧客の連絡先情報と性別を追跡する必要があります。アポイントメントについては、アポイントメントの日時と、アポイントメントの対象となる顧客を知る必要があります。

解説

上記の説明に基づいて、ビジネスのすべてのデータニーズをキャプチャするUML表記を使用してエンティティリレーションシップモデルを構築します。

II。 UML表記を使用したERモデル

上記の説明に基づいて、UML表記を使用して次の実体関連モデルを開発します。

解説

このモデルの好きなところ：

• すべての関係線は水平または垂直の位置にあります。線が交差することはありません。
• 属性名は、名前にスペースを入れずに綴られています。略語は使用されていません。
• 各関係には、関係文を作成できる2つのフレーズがあります（次のセクションを参照）。
• 図の右上隅にも「凡例」があり、図が何を表しているのか、誰が最後に図を変更したのかがわかります。

関係文

1人の顧客 かもしれません 1つ以上の予定を作成する

1つの予定 必ず 1人だけの顧客の予約

1つのSalonService かもしれません 1つ以上のServiceRenderedとしてレンダリングされたサービス

1つのServiceRendered 必ず 唯一無二のSalonServiceのレンダリング

1人の従業員 かもしれません レンダリング 1つ以上のServiceRendered

1つのServiceRendered 必ず たった1人の従業員によってレンダリングされます

1つの予定 かもしれません 1つ以上のServiceRenderedを提供するための予約

1つのServiceRendered 必ず 1つだけの予定の間に提供される特定のサービス

解説

関係文は理にかなっているはずです。この例では、動詞句に下線が引かれています。エンティティ名は太字で示されています。最小カーディナリティ（は 0の場合、はである必要があります 1）はイタリックで書かれています。最大カーディナリティは、*の場合は「1つ以上」、1の場合は「1つだけ」と表記されます。

ERモデルが完成したら、次のステップに進みます。概念的なERモデルを論理的なリレーショナルモデルに変換します。

III。リレーショナルモデルへの変換

次のステップは、実体関連図をリレーショナルモデルに変換することです。このステップでは、エンティティの識別子がリレーションのキーになります。 1対多の関係では、関係の片側から多側に外部キーがコピーされます。

お客様 （CustomerID（key）、FirstName、LastName、PhoneNumber、Street、City、State、ZipCode）

SalonService （ServiceID（キー）、ServiceName、ServiceDuration、ServicePrice、ServiceMaterials）

従業員 （EmployeeID（key）、FirstName、LastName、Street、City、State、ZipCode、PayRate）

予定 （AppointmentID（key）、AppointmentDate、AppotinmentTime、CustomerID（fk））

ServiceRendered （AppointmentID（fk）（key）、LineItemNumber（key）、ServiceID（fk）、ServiceExtendedPrice、EmployeeID（fk））

これが「最初の一連の関係」です。

解説

• ServiceRenderedに注意してください ERモデルのエンティティはIDに依存します。つまり、複合キーを形成するには、LineItemNumberに加えて属性が必要です。
• キーは（key）の指定で表示され、外部キーは（fk）の指定で表示されます。

次のステップは、関係の初期セットを正規化することです。

IV。正規化

次のステップは、関係を正規化することです。

各関係について従う手順は次のとおりです。

1. すべての属性名を含む関係を書き出します。キーと外部キーを示します。
2. 関係のサンプルデータをいくつか提供します。
3. キーを述べる 関係について、すべての機能従属性を書き留めます 。
4. 1NFからBCNF（またはプロジェクト要件によっては3NF）までの各正規形の定義を確認します。
5. 関係が正規形の定義を満たしている場合は、次に高い正規形に移動します。
6. リレーションが正規形の定義を満たさない場合（たとえば、部分キーの依存関係が含まれている、または推移的な依存関係が含まれている場合）、リレーションを2つの新しいリレーションに分割します。
   正規化プロセスを開始します。最初から、これら2つの新しい関係のそれぞれで。

顧客関係

顧客（CustomerID（key）、FirstName、LastName、CustPhone、Street、City、State、ZipCode、Gender）

サンプルデータ

キー：CustomerID

FD1：CustomerID-> FirstName、LastName、PhoneNumber、Street、City、State、ZipCode、Gender

FD2：郵便番号->市、州

1NF：関係の定義に適合します

2NF：部分的なキーの依存関係はありません

3NF：推移的な依存関係が存在します：CustomerID->ZipCodeおよびZipCode->City、State

解決策：CustomerリレーションをCustomerDataとZipCodesという名前の2つの新しいリレーションに分割します：

CustomerData（CustomerID（key）、FirstName、LastName、CustPhone、Street、ZipCode（fk）、Gender）

キー：CustomerID

FD1：CustomerID-> FirstName、LastName、PhoneNumber、Street、ZipCode（fk）、Gender

1NF：関係の定義に適合します

2NF：部分的なキーの依存関係はありません

3NF：推移的な依存関係なし

BCNF：すべての決定要因は候補キーです

ZipCodes（ZipCode（key）、City、State）

キー：ZipCode

FD1：郵便番号->市、州

1NF：関係の定義に適合します

2NF：部分的なキーの依存関係はありません

3NF：推移的な依存関係なし

BCNF：すべての決定要因は候補キーです

SalonService Relation

SalonService（ServiceID（キー）、ServiceName、ServiceDuration、ServicePrice、ServiceMaterials）

サンプルデータ：

キー：ServiceID

FD1：ServiceID-> ServiceName、ServiceDuration、ServicePrice、ServiceMaterials

1NF：ServiceMaterialsは複数値の属性として扱われる場合があります。この場合、SalonServiceは1NFにありません。

解決策：ServiceMaterialsを別の関係に分割します。

ただし、この例では、ServiceMaterialsをSalonServiceリレーションの属性として保持します。

1NF：関係の定義に適合します

2NF：部分的なキーの依存関係はありません

3NF：推移的な依存関係なし

BCNF：すべての決定要因は候補キーです

従業員との関係

Employee（EmployeeID（key）、FirstName、LastName、Street、City、State、ZipCode、PayRate）

キー：EmployeeID

FD1：EmployeeID-> FirstName、LastName、Street、City、State、ZipCode、PayRate

1NF：関係の定義に適合します

2NF：部分的なキーの依存関係はありません

3NF：推移的な依存関係が存在します：EmployeeID->ZipCodeおよびZipCode->City、State

解決策：顧客関係をEmployeeDataとZipCodesという名前の2つの新しい関係に分割します：

EmployeeData（EmployeeID（key）、FirstName、LastName、Street、ZipCode（fk）、PayRate）

キー：EmployeeID

FD1：EmployeeID-> FirstName、LastName、Street、ZipCode（fk）、PayRate

1NF：関係の定義に適合します

2NF：部分的なキーの依存関係はありません

3NF：推移的な依存関係はありません

BCNF：すべての決定要因は候補キーです

注：顧客関係が分割されたときから、すでにZipCodes関係があります。したがって、そのZipCodesリレーションを再利用します。 2番目のZipCodesリレーションを作成する必要はありません。

任命関係

Appointment（AppointmentID（key）、AppointmentDate、AppotinmentTime、CustomerID（fk））

サンプルデータ：

キー：AppointmentID

FD1：AppointmentID-> AppointmentDate、AppotinmentTime、CustomerID（fk）

1NF：関係の定義に適合します

2NF：部分的なキーの依存関係はありません

3NF：推移的な依存関係なし

BCNF：すべての決定要因は候補キーです

ServiceRendered Relation

ServiceRendered（AppointmentID（fk）（key）、LineItemNumber（key）、ServiceID（fk）、ServiceExtendedPrice、EmployeeID（fk））

サンプルデータ：

キー：AppointmentID、LineItemNumber

FD1：AppointmentID、LineItemNumber-> ServiceID（fk）、ServiceExtendedPrice、EmployeeID（fk）

1NF：関係の定義に適合します

2NF：部分的なキーの依存関係はありません

3NF：推移的な依存関係なし

BCNF：すべての決定要因は候補キーです

最終的な関係のセット

お客様 （CustomerID（key）、FirstName、LastName、PhoneNumber、Street、ZipCode（fk）、Gender）

郵便番号 （郵便番号（キー）、市、州）

SalonService （ServiceID（キー）、ServiceName、ServiceDuration、ServicePrice、ServiceMaterials）

従業員 （EmployeeID（key）、FirstName、LastName、Street、ZipCode（fk）、PayRate）

予定 （AppointmentID（key）、AppointmentDate、AppotinmentTime、CustomerID（fk））

ServiceRendered （AppointmentID（fk）（key）、LineItemNumber（key）、ServiceID（fk）、ServiceExtendedPrice、EmployeeID（fk））

解説

• 必要なZipCodesリレーションは1つだけであることに注意してください。これは、顧客と従業員の両方の関係と共有されます。
• 前述のように、この例ではServiceMaterials属性は正規化されていません。おそらく、それはモデルへの将来の割り当てまたは拡張で行うことができます。

関係が正規化されたので、構造化照会言語（SQL）を使用してデータベース管理システムでスキーマを作成できます。

V。構造化照会言語を使用したデータベーススキーマの作成

リレーションの最終セットのリレーションごとに、データベースにテーブルを作成します。

次のSQLコードは、6つのテーブルを作成し、それぞれにPRIMARYKEY制約を追加します。

 CREATE TABLE ZipCodes（zipcode VARCHAR（12）NOT NULL、city VARCHAR（36）、state VARCHAR（4）、CONSTRAINT pk_zipcodes PRIMARY KEY（zipcode））CREATE TABLE Customer（CustomerID VARCHAR（10）NOT NULL、FirstName VARCHAR（ 35）、LastName VARCHAR（35）、PhoneNumber VARCHAR（15）、Street VARCHAR（35）、ZipCode VARCHAR（12）、Gender VARCHAR（2）、CONSTRAINT pk_customer PRIMARY KEY（CustomerID））CREATE TABLE Appointment（AppointmentID VARCHAR（10） NOT NULL、AppointmentDateTime DATE、CustomerID VARCHAR（10）NOT NULL、CONSTRAINT pk_appointment PRIMARY KEY（AppointmentID））CREATE TABLE SalonService（ServiceID VARCHAR（10）NOT NULL、ServiceName VARCHAR（35）、ServiceDuration INTEGER、ServicePrice NUMBER、ServiceMaterials VARCHAR（255 ）、CONSTRAINT pk_salonservice PRIMARY KEY（ServiceID））CREATE TABLE Employee（EmployeeID VARCHAR（10）NOT N ULL、FirstName VARCHAR（35）、LastName VARCHAR（25）、Street VARCHAR（45）、ZipCode VARCHAR（12）、PayRate NUMBER、CONSTRAINT pk_employee PRIMARY KEY（EmployeeID））CREATE TABLE ServiceRendered（AppointmentID VARCHAR（10）NOT NULL、LineItemNumber INTEGER NOT NULL、ServiceID VARCHAR（10）NOT NULL、ServiceExtendedPrice NUMBER、EmployeeID VARCHAR（10）NOT NULL、CONSTRAINT pk_ServiceRendered PRIMARY KEY（AppointmentID、LineItemNumber））

外部キーの追加

次のSQLコードは、テーブルをリンクするためのFOREIGNKEY制約を追加します。

 ALTER TABLE Customer ADD CONSTRAINT fk_customer_zipcodes FOREIGN KEY（ZipCode）REFERENCES ZipCodes（ZipCode）ALTER TABLE Employee ADD CONSTRAINT fk_employee_zipcodes FOREIGN KEY（ZipCode）REFERENCES ZipCodes（ZipCode）ALTER TABLE Appointment ADD CONSTRA ）ALTER TABLE ServiceRendered ADD CONSTRAINT fk_ServiceRendered_Service FOREIGN KEY（ServiceID）REFERENCES SalonService（ServiceID）ALTER TABLE ServiceRendered ADD CONSTRAINT fk_ServiceRendered_Employee FOREIGN KEY（EmployeeID）REFERENCES Employee（EmployeeID）ALTER TABLE ServiceRendered ADD CONSTRAINT / pre> 
 

 SQLに関する解説：
 
 
ほとんどのDBMSは、日付と時刻を同じ列に格納します。そのため、AppointmentDateとAppointmentTimeは、AppointmentDateTimeという名前のデータベースの1つの列に結合されました
 
キーと外部キーは、まったく同じ名前とデータ型である必要があります。たとえば、Key CustomerIDは、CustomerテーブルではVARCHAR（10）であり、AppointmentテーブルではVARCHAR（10）です。
 
制約には、主キーの場合はpk_customer、外部キーの場合はfk_customer_zipcodesなどの意味のある名前が付けられます。
 
電話番号や郵便番号などの列は、VARCHARデータ型を使用する必要があります。 NUMBERまたはINTEGERデータ型が使用されている場合、先行ゼロは欠落します。
 
 
 

 テーブルを作成し、外部キー制約を追加すると、データベーススキーマは次のようになります。
 
 

  
 
 
リレーションシップビュー
 

 データベースツールのリレーションシップビューを使用すると、テーブル間のリレーションシップ（外部キー）を確認できます。
 

  
 

 
 
 
SQLINSERTステートメントを使用したテーブルへのデータの追加
 
 INSERT INTO ZipCodes VALUES（ '07026'、'Garfield'、'NJ'）; INSERT INTO ZipCodes VALUES（ '07621'、'Bergenfield'、'NJ'）; INSERT INTO ZipCodes VALUES（ '07010'、'Cliffside Park'、' NJ'）; INSERT INTO ZipCodes VALUES（' 07631'、' Englewood'、' NJ'）; INSERT INTO ZipCodes VALUES（' 07665'、' Teaneck'、' NJ'）; INSERT INTO Customer VALUES（' C101'、'エリア'、'フォーセット'、' 201-222-2222'、' 8989スミスロード'、' 07026'、' F'）;顧客の価値観に挿入（' C102'、'イシュワリヤ'、'ロバーツ ' 、'201 -222-3333'、 '65 Hope Rd'、 '07026'、'M'）; INSERT INTO Customer VALUES（'C103'、'Frederic'、'Fawcett'、 '201-222-2222'、 ' 8989 Smith Rd'、' 07026'、' M'）; INSERT INTO Customer VALUES（' C104'、' Goldie'、' Montand'、' 201 -222-4321'、' 5235 Ironwood Ln'、' 07026'、' F'）; INSERT INTO Customer VALUES（' C105'、' Dheeraj'、' Alexander'、' 201 -222-4545'、' 666 22nd Ave'、' 07621'、' M'）; INSERT INTO Customer VALUES（' C106'、' Josie'、' Davis'、' 201-333-6789'、' 4200 Bluejay Ave'、' 07621'、' F'）;顧客の価値観に挿入（' C107'、' Faye'、' Glenn ' 、'201 -333-4242'、 '1 522 Main St'、' 07010'、' F'）; INSERT INTO Customer VALUES（' C108'、' Lauren'、' Hershey'、' 201 -444-1313'、' 2360 Maxon Rd'、' 07631'、' F'）; INSERT INTO SalonService VALUES（' SV101'、' Men''s Haircut'、20、22、' None'）; INSERT INTO SalonService VALUES（' SV102'、' Women''s Haircut'、30、32 、'なし'）; INSERT INTO SalonService VALUES（'SV103'、'チャイルドヘアカット'、20、15、'なし'）; INSERT INTO SalonService VALUES（'SV104'、'女性のヘアカラー'、60、76 、'Color、Reagent、Gloves、Reagent Brush、Foil'）; INSERT INTO SalonService VALUES（'SV105'、'Women''s Hair Style'、45、56、'Shampoo、Conditioner'）; INSERT INTO SalonService VALUES（ ' SV106'、'男性のヘアスタイル'、45、46、'シャンプー、コンディショナー'）; INSERT INTO Employee VALUES（' E300'、' Joy'、' Aveda'、' 46 Easton Ave。'、' 07026 ' 、18）; INSERT INTO Employee VALUES（'E400'、'Geraldo'、'Geraldo'、 '12 Fortis Blvd. Apt。 2A'、' 07026'、22）; INSERT INTO Employee VALUES（' E500'、' Koy'、' Petruzzio'、' 70 Wilard St.'、' 07026'、20）; INSERT INTO Employee VALUES（' E600'、 'Landry'、'Monroe'、 '73 Holly Terrace'、 '07010'、18）; INSERT INTO Employee VALUES（'E700'、'Pat'、'Reese'、 '2 Lincoln Place'、 '07010'、23）; INSERT INTO Employee VALUES（'E800'、'Winter'、'Tanner'、 '215 Elm Ave'、 '07665'、23）​​; INSERT INTO Appointment VALUES（'A400'、 '10/22/2017 11:00： 00 AM'、' C101'）; INSERT INTO Appointment VALUES（' A401'、' 11/06/2017 12:45:00 PM'、' C102'）; INSERT INTO Appointment VALUES（' A402'、' 12/07 / 2017 02:00:00 PM'、' C106'）; INSERT INTO Appointment VALUES（' A403'、' 12/18/2017 03:30:00 PM'、' C106'）; INSERT INTO Appointment VALUES（' A404 '、' 12/21/2017 11:30:00 AM'、' C108'）; INSERT INTO Appointment VALUES（' A405'、' 12/31/2017 10:00:00 AM'、' C107'）; INSERT INTO Appointment VALUES（'A406'、 '01/11/2018 03:15:00 PM'、'C103'）; INSERT INTO Appointment VALUES（'A407'、 '01/12/2018 02:30:00 PM'、 'C104'）; INSERT INTO Appointment VALUES（'A408'、 '0 1/22/2018 04:00:00 PM'、' C105'）; INSERT INTO ServiceRendered VALUES（' A400'、1、' SV104'、75、' E400'）; INSERT INTO ServiceRendered VALUES（' A400'、2 、'SV102'、25、'E400'）; INSERT INTO ServiceRendered VALUES（'A401'、1、'SV101'、22、'E500'）; INSERT INTO ServiceRendered VALUES（'A402'、1、'SV104'、75 、'E600'）; INSERT INTO ServiceRendered VALUES（'A402'、2、'SV102'、30、'E800'）; INSERT INTO ServiceRendered VALUES（'A403'、1、'SV105'、50、'E300'）; INSERT INTO ServiceRendered VALUES（'A404'、1、'SV105'、55、'E300'）; INSERT INTO ServiceRendered VALUES（'A405'、1、'SV102'、30、'E700'）; INSERT INTO ServiceRendered VALUES（ ' A405'、2、' SV104'、70、' E700'）; INSERT INTO ServiceRendered VALUES（' A405'、3、' SV105'、50、' E700'）; 
 
データサンプルの解説
 
 
テーブル間の関係をテストし、アプリケーション開発者に何かを提供するのに十分なデータを追加します。
 
データが追加される順序に注意してください。たとえば、CustomerまたはEmployee（どちらも外部キーとしてZipCodeを使用）を挿入する前に、すべてのZipCodeを最初に挿入する必要があります。
 
引用符が埋め込まれたVARCHARデータを追加するときは、2つの引用符を一緒に使用します。例：「女性のヘアスタイル」
 
この時点で、データベーススキーマは、アプリケーション開発者がフォーム、レポート、クエリの設計に取り掛かる準備ができています。
 
 

 データベーススキーマが作成され、いくつかのサンプルデータが入力されたので、データベースアプリケーションを開発できます。
 

 
 
VI。データベースアプリケーション
 

 データベースアプリケーションは、ナビゲーションフォーム上で相互にリンクされた一連のフォーム、レポート、およびクエリで構成されています。
 

 ナビゲーションフォームは、データベースを開いたときに最初に表示されるフォームです。
 
 
ナビゲーションフォーム
 

  
 

 左側の選択をクリックすると、さまざまなデータ入力フォームとレポートを表示できます。
 
 
顧客データ入力フォーム
 

  
 

 顧客データ入力フォームは、既存の顧客を検索し、新しい顧客情報を入力するために使用されます。 CityフィールドとStateフィールドは、コンボボックスからZipCodeを選択することで自動的に入力されます。フォームには、名前と名前を適切な大文字と小文字に変換し、空のCustomerIDフィールドが表示されたときに新しい一意の顧客IDを生成するためのカスタムVBAコードがいくつかあります。新しいレコードを作成した後。
 
 

  
 
 
サロンサービスデータ入力フォーム
 

  
 

 サロンサービスデータ入力フォームは、新しいサロンサービスのクエリ、更新、追加に使用されます。
 
 
予約データ入力フォーム
 

  
 

 予定データ入力フォームは、顧客の新しい予定を作成するために使用されます。顧客フォームと同様に、新しいレコードが作成された後、空白の[予定ID]フィールドをクリックすると、新しい予定IDを作成できます。顧客は、以下に示すように、顧客IDコンボボックスから選択できます。
 

  
 

 これが予約を行う新規顧客である場合、ユーザーは[新規顧客]ボタンをクリックして、顧客データ入力フォームを表示できます。新しい顧客の情報が保存された後、ユーザーは予約データ入力フォームに戻って予約を行うことができます。
 
 
予約およびサービスフォーム
 

  
 

 このフォームの目的は、予定に関連するさまざまなサービスを入力することです。このフォームは、顧客の請求書を生成するためにも使用できます。サービスと従業員は、以下に示すように、それぞれのコンボボックスから選択できます。
 

  
 

 
顧客の予定の合計レポート
 

  
 

 このレポートは、各顧客が費やした予定の数と合計金額の概要を提供します。
 
 

 クエリに基づく：
 
 SELECT Customer.CustomerID、FirstName、LastName、SUM（q.TotalSpent）AS TotalSpent、COUNT（q.AppointmentID）AS NumberOfAppointmentsFROM Customer、Appointment、Query_Total_Spent_Each_Appointment AS qWHERE Customer.CustomerID =Appointment.CustomerID AND Appointment.A AppointmentIDGROUP BY Customer.CustomerID、FirstName、LastNameORDER BY LastName、FirstName; 
 
 

 そして、Total_Spent_Each_Appointmentをクエリします
 
 SELECT Appointment.AppointmentID、SUM（ServiceExtendedPrice）AS TotalSpentFROM Appointment、ServiceRenderedWHERE Appointment.AppointmentID =ServiceRendered.AppointmentIDGROUP BY Appointment.AppointmentIDORDER BY Appointment.AppointmentID; 
 
 
サービスと割引のレポート
 

  
 

 このレポートには、通常のサービス価格、延長価格、および過去に提供されたサービスに適用された割引額の表示の合計を含む各サービスが表示されます。
 
 

 クエリに基づく：
 
 SELECT SalonService.ServiceID、ServiceName、SUM（ServicePrice）AS TotalServicePrice、SUM（ServiceExtendedPrice）AS TotalExtPrice、FORMAT（1.0-（SUM（ServiceExtendedPrice）/ SUM（ServicePrice））、 "0.00％"）AS DiscountFROM SalonService、ServiceRenderedWHERE SalonService.ServiceID =ServiceRendered.ServiceIDGROUP BY SalonService.ServiceID、ServiceNameORDER BY SalonService.ServiceID、ServiceName; 
 
 
顧客アドレスレポート
 

  
 

 このレポートには、各顧客の完全な名前と住所が表示されます。
 

 
 
VII。結論
 

 データベースアプリケーションの開発は、概念モデリングから始まり、論理モデリング、正規化、物理的な実装、およびアプリケーション開発を含む一連の構造化されたステップを経て進むシステム開発ライフサイクルに従います。ヘアサロンプロジェクトの例は、これらの主要なステップのそれぞれを示しています。ただし、一部の詳細は完全には文書化されていません。たとえば、サロンサービスの関係を正規化して、各サービスで使用されるさまざまな資料を考慮に入れるために、追加の作業が必要になる場合があります。他のVBAコードなどの追加のアプリケーション実装の詳細、および各フォームとレポートの使用に関するより詳細な説明も追加できます。