ایجاد لیست #موجودیت و #ویژگی
فرض کنید شما یک تیم طراحی متشکل از کاربران نهایی، برنامه نویسان نرم افزار و کارکنان پشتیبانی از پایگاه داده تشکیل داده اید. تیم شما موافقت کرده است از روش نرمال سازی برای تجزیه و تحلیل داده ها استفاده کرده و اصطلاحات موجودیت و ویژگی را تعریف و بررسی نماید. در ابتدا چه کاری باید انجام شود؟
به عنوان نقطه شروع، گزارش ها و فرم های موجود جهت شناسایی نیازهای داده ای جستجو می شود. اگر بخشی از سیستم قبلا مکانیزه شده است، اسناد  مربوط به طرح بندی و پایگاه داده آن مطالعه می گردد. اگر برخی وظایف قبلا مکانیزه شده است، احتمالاً به داده های آنها برای گسترش سیستم موجود یا ایجاد سیستم جدید احتیاج دارید. از کاربران بپرسید که چه چیز دیگری برای پیگیری نیاز دارند. چه اطلاعاتی را برای آینده مد نظر دارند؟ شما می خواهید نیازهای آینده را پوشش دهید حتی اگر فقط داده های شش ماه گذشته موجود باشند.
از طرف دیگر، مشخص کنید که چه نیازهایی تغییر می کند. به عنوان مثال گزارشی که برای پنج سال گذشته تولید شده است و دیگر استفاده نمی شود باید حفظ شود زیرا آن داده ها به کسب و کار امروز (و فردا) مربوط هستند.
برای شناسایی #عناصر_داده، طوفان فکری را امتحان کنید. مخصوصا مشارکت کاربران نهایی کم تجربه آنها در بحث ها مفید است و می تواند کامل کننده پیشنهادات پردازش کنندگان داده باشد، مثلا "اگر این نوع داده ها را داشته باشید، این وظایف را می توانید انجام دهید". به عنوان مثال، صورت مواد اولیه یک فروشگاه جهت تامین، باید شامل اقلام سفارش داده شده هم باشد.
در جلسه طوفان فکری، همه ایده ها و پیشنهادات را بدون سوال بپذیرید و بعدا آنها را پالایش نموده یا در موردشان تتصمیم گیری نمایید.
برای سازماندهی اطلاعات لیست موجودیت و ویژگی از یک ابزار مدل سازی داده، مانند erwin استفاده نمایید.
ابزارهای مدل سازی داده برنامه هایی هستند که اجازه می دهند موجودیت ها و ویژگی های مرتبط با آنها را تعریف کرده و ارتباط بین موجودیت ها (مدل داده) را نشان دهید.
بعلاوه آنها امکان نگاشت طراحی منطقی به طراحی فیزیکی را فراهم کرده و می توانند عبارات #DDL ( #زبان_تعریف_داده ) برای ایجاد جداول در نرم افزارهای مدیریت پایگاه داده ( #DBMS ) مانند #sql_server و #oracle تولید نمایند.
پس از آماده شدن این گزارش ها، آنها را بازبینی کنید تا مطمئن شوید هر ویژگی دقیق و صحیح تعریف شده است. همه اعضای تیم باید در مورد این تعاریف به توافق برسند. اختلاف نظرها اغلب منجر به شناسایی و ایجاد ویژگی های اضافی می گردد. خوشبختانه یک ابزار مدل سازی داده امور راهبری مورد نیاز را به طور چشمگیری کاهش می دهد.

#The_Order_Entry_Model
یک محیط کاری را به عنوان نمونه برای نشان دادن فرایند طراحی پایگاه داده در نظر بگیرید. فرض کنید شما عضو تیم طراحی شرکتی هستید که به تبلیغ و فروش کالا در اینترنت می پردازد.
• مشتریان به وب سایت شرکت مراجعه نموده، کالاهای تبلیغ شده برای فروش را بررسی کرده، مواردی را انتخاب و سفارش می دهند. سپس سفارشات از انبار برای مشتری ارسال می شود.
• هر قلم کالای تبلیغ شده دارای یک سطح سفارش مجدد است. وقتی موجودی آن قلم کالا کمتر از آن مقدار شد، اقلام کالا بر اساس قیمت فروش فعلی از تأمین کنندگان موجود سفارش داده می شود.
مدل داده ای که ایجاد می شود شامل داده های مورد نیاز برای سفارشات مشتریان، تحویل از انبار، نظارت بر مقدار موجودی و سفارش مجدد کالاها از تامین کنندگان درصورت نیاز می باشد.
به عنوان عضوی از تیم طراحی، موارد مذکور را برای این محیط در نظر بگیرید و سعی کنید پنج یا شش موجودیت مناسب لحاظ نمایید (مانند مشتری). سپس، سعی کنید حداقل چهار ویژگی برای هر موجودیت مشخص کنید (مانند نام مشتری ، آدرس و تلفن). مطمئن شوید که هر ویژگی را که شناسایی می کنید به طور شفاف تعریف نمایید.
هنگامی که لیست خود را کامل کردید، آنرا با لیست زیر مقایسه کنید. این به عنوان نقطه شروع برای مرحله بعدی تجزیه و تحلیل است. البته لیست زیر شامل چندین مورد خطای عمدی است که حین فرایند نرمال سازی برطرف می گردند.
 

Attribute Description
Customer
CustomerTelephoneNumber The customer’s telephone number
CustomerName The customer’s name
CustomerStreetAddress The street name associated with the customer’s account
CustomerCity The city in which the customer lives
CustomerState The state in which the customer lives
CustomerZipCode The customer’s zip code
CustomerCreditRating The credit rating for this customer
OrderNumber An order number for this customer
Order
OrderNumber A unique identifier for each order
CustomerPhoneNumber The customer’s telephone number
CustomerName The unique name for this customer
OrderDate The date when the order was placed
NumberOfDays The number of days from when the order was placed until shipped
CustomerStreetAddress The street address for where the order is to be shipped
CustomerCity The city to which the order is to be shipped
CustomerState The state to which the order is to be shipped
CustomerZipCode The zip code associate with the shipping address
CustomerCreditCardNumber The credit card number used for this purchase
CustomerCreditCardName The customer’s name on the credit card used
StockNumber The stock number for the item purchased
ShippingDate The date the order was shipped
Advertised_Item
ItemNumber The unique identifier for each Advertised_Item
ItemDescription A description of the item advertised
ClothingFlag A code identifying clothing items
HealthFlag A code identifying items as Health and Beauty
ItemWeight The shipping weight for each item
ItemColor The color of the item
ItemPrice The selling price of the item sold
SupplierCode The unique identifier for the supplier of this item
OrderNumber The order number on which this item appears
Supplier
SupplierID A unique identifier for each supplier
CompanyName The unique name for this supplier
SupplierStreetAddress The street address for this supplier’s main office
SupplierCity The city in which the supplier’s main office is located
SupplierState The state in which the supplier’s main office is located
SupplierZipCode The zip code for the supplier’s main office
StockNumber The unique identifier for each advertised item
Purchased_Item
ItemNumber The unique identifier for each item on an order
ItemDescription The description of the item advertised
QuantityOrdered The number of items purchased
SellingPrice The price of the item purchased
ShippingDate The date the item purchased was shipped to the customer

صحت سنجی لیست موجودیت و ویژگی
قبل از شروع فرایند نرمال سازی، لیست موجودیت و ویژگی اولیه باید جهت شناسایی خطاها بررسی شود.

خطای نوع 1 – هم معنی ها
این خطا زمانی اتفاق می افتد که از دو نام متفاوت برای ویژگی یکسان استفاده شود. اگر یک ویژگی در بیش از یک موجودیت وجود دارد، مطمئن شوید که همه موجودیت ها از نام یکسان برای آن ویژگی استفاده می کنند.
به عنوان مثال، ویژگی های "SupplierCode" و "SupplierID" هر دو به عنوان شناسه منحصر به فرد (کلید اصلی) برای تأمین کننده در نظر گرفته شده است درحالیکه با الفاظ متفاوت بیان شده اند و این نشان دهنده یک خطا است.
موجودیت Supplier
خطا ==> SupplierID ==> SupplierCode
استفاده از نام های متفاوت برای ویژگی یکسان مشکلات زیادی ایجاد می نماید، از جمله عدم تشخیص روابط یک به چند (1: M) هنگام ایجاد مدل داده.
موجودیت Supplier
اصلاح ==> SupplierCode ==> SupplierID

خطای نوع 2 - هم نام ها
این خط برعکس خطای اول است. همانطور که نمی توانید از نام های مختلف برای یک ویژگی استفاده کنید، نمی توانید از یک نام برای ویژگی های مختلف استفاده کنید.
به عنوان مثال، ویژگی "CompanyName" در موجودیت مشتری با عنصر داده "CompanyName" در موجودیت تأمین کننده متفاوت است و این یک خطای دیگر در تعریف داده است.

Customer Supplier
CompanyName - The unique name
for this customer <== error
CompanyName - The unique
name for this supplier <== error
One or both names must be changed to reflect their differences.
Customer Supplier
CustomerName - The unique name
for this customer <== correction
SupplierName - The unique name
for this supplier <== correction

خطای نوع 3 – افزونگی اطلاعات
تشخیص این خطا، که در آن اطلاعات یکسان به دو شکل یا روش مختلف ذخیره می شوند، کمی دشوارتر است. یکی از راه های بررسی این خطا این است که آیا مقدار هر ویژگی شناخته شده است یا از طریق ویژگی های تعریف شده دیگر قابل حصول است.
به عنوان مثال، در موجودیت کارمند، ذخیره سن کارمند افزونگی اطلاعات است وقتی تاریخ تولد کارمند نیز به عنوان یک ویژگی ذخیره می شود.

Employee
EmployeeAge <== error
EmployeeBirthDate <== error
 

در این مثال ، حذف EmployeeAge شرایط خطا را برطرف می کند. در صورت لزوم، سن کارمند را می توان با استفاده از EmployeeBirthDate و تاریخ فعلی بدست آورد.

خطای نوع 4 - داده های انحصاری متقابل
این خطا برای زمانی است که در یک موجودیت دو ویژگی از نوع بله/خیر موجود باشد که همزمان نتوانند مقدار بله داشته باشند.
.به عنوان مثال، یک موجودیت کارمند با ویژگی های "متاهل" و "مجرد" در نظر بگیرید.

Employee
Married <== error
Single <== error
 

در این حالت، می توان با ایجاد ویژگی "MaritalStatus" که دارای مقادیر M (متاهل) یا S (مجرد) است خطا را برطرف نمود.

Employee
MaritalStatus—An indicator of
the Employee’s marital status

دراینجا به اصلاح خطاهای فوق در لیست قبلی می پردازیم:
اصلاح خطای نوع 1 – هم معنی ها
Customer Order
خطا ==> CustomerPhoneNumber ==> CustomerTelephoneNumber
به ویژگی های شماره مشتری و شماره تلفن مشتری در موجودیت سفارش توجه نمایید که هر دو به یک ویژگی ولی با نام های مختلف اشاره دارد.

Customer Order
CustomerTelephoneNumber CustomerTelephoneNumber <== correction
Advertised_Item Supplier
ItemNumber <== error StockNumber <== error
Attribute Description
Customer
CustomerTelephoneNumber The customer’s telephone number
CustomerName The customer’s name
CustomerStreetAddress The street name associated with the customer’s account
CustomerCity The city in which the customer lives
CustomerState The state in which the customer lives
CustomerZipCode The customer’s zip code
CustomerCreditRating The credit rating for this customer
OrderNumber An order number for this customer
Order
OrderNumber A unique identifier for each order
CustomerTelephoneNumber The customer’s telephone number
CustomerName The unique name for this customer
OrderDate The date when the order was placed
ShippingStreetAddress The street address for where the order is to be shipped
ShippingCity The city to which the order is to be shipped
ShippingState The state to which the order is to be shipped
ShippingZipCode The zip code associate with the shipping address
CustomerCreditCardNumber The credit card number used for this purchase
CustomerCreditCardName The customer’s name on the credit card used
StockNumber The stock number for the item purchased
ShippingDate The date the order was shipped
Advertised_Item
ItemNumber The unique identifier for each Advertised_Item
ItemDescription A description of the item advertised
ItemDepartment A code classifying the item into one of the various product
categories of items for sale
ItemWeight The shipping weight for each item
ItemColor The color of the item
ItemPrice The selling price of the item sold
SupplierID The unique identifier for the supplier of this item
OrderNumber The order number on which this item appears
Supplier
SupplierID A unique identifier for each supplier
CompanyName The unique name for this supplier
SupplierStreetAddress The street address for this supplier’s main office
SupplierCity The city in which the supplier’s main office is located
SupplierState The state in which the supplier’s main office is located
SupplierZipCode The zip code for the supplier’s main office
ItemNumber The unique identifier for each advertised item
Item_Ordered
ItemNumber The unique identifier for each item on an order
ItemDescription The description of the item advertised
QuantityOrdered The number of items purchased
SellingPrice The price of the item purchased
ShippingDate The date the item purchased was shipped to the customer
 

همینطور ویژگی ItemNumber شناسه منحصر به فرد برای کالا می باشد که همان کار ویژگی StockNumber در موجودیت تأمین کننده را انجام می دهد بنابراین از نام یکسان باید در هر دو موجودیت استفاده شود.
موجودیت Supplier
اصلاح StockNumber ==> ItemNumber

اصلاح خطای نوع 2 - هم نام ها
در لیست قبلی ویژگی آدرس مشتری در هر دو موجودیت مشتری و سفارش با اسامی مشابه وجود داشت در حالیکه آنها به عناصر داده ای متفاوت اشاره می کنند. 

Customer Order
CustomerStreetAddress <== error CustomerStreetAddress <== error
CustomerCity <== error CustomerCity <== error
CustomerState <== error CustomerState <== error
CustomerZipCode<== error CustomerZipCode<== error
 

ویژگی آدرس در موجودیت مشتری به محل سکونت مشتری اشاره دارد اما ویژگی آدرس در موجودیت سفارش به محل حمل سفارش اشاره دارد.

Customer Order
CustomerStreetAddress ShippingStreetAddress <== correction
CustomerCity ShippingCity <== correction
CustomerState ShippingState <== correction
CustomerZipCode ShippingZipCode <== correction

اصلاح خطای نوع 3 – افزونگی اطلاعات
ویژگی NumberOfDays در سفارش برای مدت زمان انجام سفارش تا حمل سفارش تعریف شده است در حالیکه همان نتیجه می تواند از تفاوت ویژگی های OrderDate و ShippingDate بدست آید. بنابراین ویژگی NumberOfDays قابل حذف است.

اصلاح خطای نوع 4 - داده های انحصاری متقابل
برای کالای تبلیغ شده، ویژگی ClothingFlag برای طبقه بندی کالا به عنوان لباس استفاده شده و HealthFlag برای طبقه بندی کالا به عنوان بهداشتی/آرایشی بکار رفته است. در حالیکه هر دو همزمان نمی توانند درست باشند.
این خطا با حذف هر دو ویژگی ازکالا و افزودن ویژگی جدید ItemDepartment رفع می شود که شامل کدی است برای پوشش طبقه بندی های مختلف کالای ارائه شده.
 

#Normalization

#Database