طراحی پایگاه داده. تعریف فیلدهایی با مقادیر منحصر به فرد در هر رکورد

1.1. انواع میز;
1.2. انواع دایرکتوری ها;
1.3. انواع رباط;
2. تعمیم طبقه بندی;
2.1. طبقه بندی به صورت جدولی؛
2.2. طبقه بندی به صورت شماتیک؛
3. برخی از نظرات در مورد کاربرد طبقه بندی;
3.1. استفاده از طبقه بندی هنگام عادی سازی جداول.
نتیجه.

دلیل مقاله و برخی مفاهیم کلیدی

اغلب اوقات در آموزش رشته "پایگاه های اطلاعاتی" شرکت می کردم. یک بار خودم را مطالعه کردم ... حتی مجبور شدم یک دوره کامل را برای دوستان و آشنایان برگزار کنم. در طول آموزش متوجه شدم که در مرحله درک جداول و نحوه استفاده از آنها مشکلاتی وجود دارد. بسیاری به سادگی نتوانستند و نمی توانند ساده ترین پایگاه های داده را توسعه دهند. پس از نگاهی دقیق تر به مفهوم جداول و یک طبقه بندی کوچک، دشواری درک جداول در پایگاه داده های رابطه ای تقریباً همیشه ناپدید می شود. بنابراین!

این مقاله طبقه بندی کوچکی از جداول را بر اساس یکپارچگی و افزونگی در نظر می گیرد. چه مفهومی داره؟ این به این معنی است که مثال‌هایی ارائه می‌شود که توضیح می‌دهند چه ساختار جدولی می‌توانید برای جلوگیری از افزونگی (تلاش برای جلوگیری از) و دستیابی به ثبات در پایگاه‌های داده رابطه‌ای انجام دهید.

برای درک، ما خواهیم داد تعاریف کوتاهیکپارچگی و افزونگی داده ها:

یکپارچگی داده- این ویژگی توانایی بازیابی دیگران از یک داده است، در حالی که وحدت معنایی این داده ها و رابطه بین آنها (بین داده ها) را از دست نمی دهد.

افزونگی داده ها- این وضعیت پایگاه داده ای است که داده های اضافی در جداول موجود است.

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

1.1. انواع میز

بیایید کمی عمیق تر به طبقه بندی کوچکی از جداول بر اساس نوع ساختار آنها برویم. جداول را به دو قسمت تقسیم کنید نمای کلی... نوع اول جداول مرجع و دوم جداول پیوند خواهد بود.

شکل 1. مراجع و پیوندها

اطلاعات موجود در جداول را می توان به دو نوع تقسیم کرد. اطلاعاتی که اشیاء (موضوعات)، ارتباطات و اطلاعاتی را توصیف می کند که اقدامات، فرآیندها، رویدادها و غیره را توصیف می کند.

کتاب های مرجع حاوی اطلاعاتی در مورد اشیا و موضوعات، ارتباطات است. بسته ها حاوی اطلاعاتی درباره اقدامات، فرآیندها، رویدادها و غیره هستند.

بسته ها داده های گرفته شده از جداول کتاب های مرجع را ذخیره می کنند. از آنجایی که تکرار همان داده ها در هنگام توصیف اشیا (موضوعات) و هنگام توصیف تعامل آنها سودمند نیست، داده های مربوط به اشیا (موضوعات) در فهرست ها وارد می شوند و جداول پیوند داده های اشیاء (موضوعات) را ذخیره نمی کنند. شکل خالص، اما فقط به آنها پیوند می دهد (کلید خارجی). بنابراین، bindings داده‌های مربوط به تعامل اشیاء (موضوع) و پیوندها را به خود اشیا (موضوع) ذخیره می‌کند (کلید خارجی). این "پیوندها" کلیدهای اصلی در جداول مرجع هستند. اما بعداً در مورد آن بیشتر ...

تفاوت بین یک کتاب مرجع و یک پیوند در این واقعیت بیان می شود که جداول مرجع می توانند مستقل و مستقل باشند (یعنی هنگام خواندن داده های برخی از کتاب های مرجع به طور کلی می توانید معنایی را درک کنید) و جداول پیوند تقریباً هرگز.

دایرکتوری ها را می توان به چندین نوع تقسیم کرد. اینها مراجع ایستا، ایستا-دینامیک و دینامیک هستند. البته، به سختی می توان یک کتاب مرجع کاملا ثابت نامید، زیرا همه چیز در این جهان می تواند تغییر کند. یا تقریباً همه چیز.

مرجع استاتیک- دایرکتوری، داده‌های مربوط به اشیا، موضوعات، پیوندهایی که در آنها یا پس از اصلاح اولیه هرگز تغییری نمی‌یابند، یا به ندرت اصلاح می‌شوند که می‌توان از آن صرف نظر کرد.

نمونه ای از این فهرست ها لیستی از ماه ها با نام و اعداد، فهرست روزهای هفته، فهرست فصل ها، فهرست اقیانوس ها و غیره است.

جدول 1. نمونه ای از دایرکتوری های ثابت

- دایرکتوری که داده ها را روی پیوندها ذخیره می کند، اگر پیوندها ماهیت مرجع داشته باشند. چنین مرجعی ممکن است حاوی کلیدهای خارجی باشد.

اکثر یک مثال خوبجدولی با اطلاعات پزشکی مانند وزن وجود خواهد داشت. لیست افرادی که وزن آنها اندازه گیری می شود اغلب تغییر نمی کند. اما داده های مربوط به وزن آنها می تواند هر روز تغییر کند. کتاب های مرجع استاتیک-دینامیک تنها کتاب های مرجعی هستند که می توانید آگاهانه هر اطلاعاتی را در آنها تکرار کنید. مثال دیگر می تواند راهنمای حقوق و دستمزد بر اساس عنوان شغلی (بر اساس کد شغل) باشد.

جدول 2. نمونه ای از دایرکتوری های استاتیک-دینامیک

دایرکتوری های پویا- اینها جداول، داده های مربوط به اشیا، موضوعات، پیوندهایی هستند که اغلب در آنها تغییر می کنند و در جداول دیگر استفاده می شوند. آنها با دایرکتوری های ایستا فقط در دفعات اصلاح داده ها در آنها تفاوت دارند.

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

جدول 3. نمونه ای از دایرکتوری های پویا

شکل 2. انواع دایرکتوری ها

جداول پیوند را می توان به دو نوع تقسیم کرد.

این دسته کتاب مرجع(ما بلافاصله توضیح خواهیم داد که پیوند مرجع یک مرجع نیست، به این دلیل نامگذاری شده است که فیلدهایی در آن وجود دارد که یک مرجع را تشکیل می دهند، اما نمی توان آنها را در یک مرجع برجسته کرد). جدولی که کلیدهای خارجی، داده هایی که مرجع نیستند و فیلدهایی حاوی داده هایی که یک مرجع را تشکیل می دهند، ذخیره می کند، اما نمی توان آنها را به یک جدول مرجع جداگانه جدا کرد.

نمونه ای از کتاب مرجع پیوند، جدول تراکنش های پرداخت خواهد بود. یا جدولی با اطلاعات مربوط به یک مسابقه فوتبال.

جدول 4. نمونه ای از یک بسته کتاب مرجع

و دسته(بله، فقط یک دسته). این جدولی است که فقط کلیدهای خارجی و داده هایی را ذخیره می کند که نمی توانند به عنوان مرجع طبقه بندی شوند، مانند تاریخ یا مقادیر فیلدهای منطقی.

نمونه ای از یک بسته، جدول ثبت خودکار پایانه پردازش داده خواهد بود.
به هر حال، به راحتی می توان حدس زد که صحافی ها تقریباً هرگز در هیچ کجا استفاده نمی شوند، زیرا اغلب داده هایی وجود دارد که می توان در پایگاه داده نوشت، اما در کتاب های مرجع موجود نیست، بنابراین نمی توان یک کلید خارجی را با آنها مرتبط کرد.

جدول 5. نمونه ای از یک بسته نرم افزاری

لازم به توضیح است که این فیلدها چه هستند که یک کتاب مرجع را تشکیل می دهند، اما نمی توان آنها را در جدول مرجع جداگانه تفکیک کرد. نمونه هایی از این زمینه ها فیلدهای "نظر"، "شکایت"، "توضیحات"، "پیشنهاد" هستند. در یک کلام، اگر یک مثال محبوب بیاورید، قسمت "پیام" در جدول پایگاه داده هر شبکه اجتماعی ...

شکل 3. انواع رباط ها

2. تعمیم طبقه بندی

2.1. طبقه بندی به صورت جدولی

نمای جدول	شرح	نمونه هایی از	جوانب مثبت (+)	معایب (-)
مرجع استاتیک	جدول. داده های آن برای جداول دیگر گرفته شده است. فقط کلید اصلی را می توان از مرجع در سایر جداول استفاده کرد. دایرکتوری ایستا باید حاوی اطلاعاتی باشد که یا اصلاً تغییر نمی کند یا به ندرت تغییر می کند که بتوان از آن غفلت کرد. هنگامی که شما نیاز به دریافت نام، نامگذاری، هنجارها، شاخص های کمی یا کیفی دارید، به یک مرجع ثابت ارجاع داده می شود (کلید خارجی). دیگر.	فهرست (نام و شماره) ماه ها. فهرست انبارها و کارگاه های شرکت. کتابچه راهنمای قوانین بازی.	گاهی جایگزین می کند توابع سیستم DBMS اجازه می دهد تا کار انعطاف پذیرتر با برخی از داده ها. در صورتی که اطلاعات به ندرت تغییر کند، در مورد عواقب جدی هشدار می دهد.	اگر جدول جایگزین فضای ذخیره سازی سیستم شود، استفاده از جدول با هر ساختاری می تواند سرعت شما را کاهش دهد. من باید بنویسم توابع اضافیو پردازش برای یک جدول داده شده، که همیشه به درستی بهینه نشده اند. در برخی موارد امکان بهینه سازی وجود ندارد.
مرجع استاتیک-دینامیک	جدول. داده های آن برای جداول دیگر گرفته شده است. از یک مرجع در جداول دیگر، نمی توانید از کلید خارجی این مرجع استفاده کنید، اما می توانید از کلید اصلی استفاده کنید.	حقوق با مرجع شغلی کتاب مرجع (اندازه کفش، وزن، قد، سایز سر) پارامترهای فیزیولوژیکی. دایرکتوری (مدیران، شرکت ها) حاوی شرکت ها و مدیرانی است که این شرکت ها به آنها خدمت می کنند و به آنها توجه می کنند.		مرجع جدا شده از مجموعه کتاب مرجع، در هیچ کجا ناپدید نمی شود و هیچ ارتباط رابطه ای ندارد که به آن اجازه دهد به یک مرجع ایستا یا پویا تبدیل شود. این بدان معنی است که همیشه اضافی است.
دایرکتوری پویا	جدول. داده های آن اغلب برای جداول دیگر گرفته می شود. فقط کلید اصلی را می توان از مرجع در سایر جداول استفاده کرد. یک مرجع پویا باید حاوی اطلاعاتی باشد که مرتباً تغییر می کند.	کتاب مرجع مشتری. دایرکتوری تامین کنندگان فهرست پیمانکاران کتاب مرجع مدیران شرکت. دایرکتوری کارگران کتاب مرجع دانش آموزان.	به شما امکان می دهد داده های پویا را ذخیره کنید و در عین حال ارجاع بدون ابهام به آنها را ممکن می سازد.	اغلب، نوع تجمعی تقسیم نمی شود، که باعث ایجاد افزونگی خاصی می شود.
مرجع پیوند	جدول. داده های حاصل از آن را نمی توان در جداول دیگر قرار داد، اما داده های جداول دیگر را می توان بر اساس آنها ایجاد کرد.	معاملات پرداخت حراجی. حرکات بین فاکتوری برنامه حمل و نقل.	اجازه می دهد تا نرمال سازی انعطاف پذیر را طبق طرح "مرجع-پیوند" = "پیوند" + "مرجع استاتیک-دینامیک" انجام دهید.	پیوند مرجع پس از نرمال‌سازی به پیوند تبدیل می‌شود و افزونگی داده‌ها را بدون تأثیر بر یکپارچگی به حداقل می‌رساند، با این حال، قابل تقسیم نیست و هنگام بایگانی در جدول فعلی نمی‌توان آن را بهینه کرد.
دسته	جدول. داده های حاصل از آن را نمی توان در جداول دیگر قرار داد، اما داده های جداول دیگر را می توان بر اساس آنها ایجاد کرد. جدول نمی تواند حاوی چند تاپل باشد که مقادیر مشخصه آنها غیرقابل تقسیم و منحصر به فرد باشد.	ثبت خودکار خطاها در برنامه. گزارش درخواست سرور ردیابی نتایج گزارش در مورد تخلیه و بارگیری قطعات. گزارشات امنیتی خودکار	بسته‌بندی، افزونگی داده‌ها را بدون تأثیرگذاری بر یکپارچگی به حداقل می‌رساند.	انباشته شدن یک جدول تقسیم ناپذیر است. بهینه سازی مشکل است.

جدول 6. طبقه بندی

2.2. طبقه بندی به صورت شماتیک

شکل 4. طرح طبقه بندی جداول در پایگاه داده های رابطه ای بر اساس یکپارچگی و افزونگی داده ها

3. برخی از نظرات در مورد کاربرد طبقه بندی

3.1. استفاده از طبقه بندی هنگام عادی سازی جداول

فرآیند عادی سازی، اگر برخی از مراحل را در نظر نگیرید (اما نتایج این مراحل را در نظر بگیرید!) - این جداول معمول "تقسیم" جداول به جداول کوچکتر با ایجاد یک رابطه رابطه ای بین آنها به طور مستقیم یا از طریق میانی است. جداول (رابطه چند به چند). رابطه رابطه ای ممکن است همیشه به معنای رابطه رابطه ای نباشد!

تبدیل یک مرجع پویا یا ایستا به یک مرجع استاتیک-دینامیک، و یک مرجع پیوند دهنده به یک دسته، مانند یک مرجع استاتیک-دینامیک به یک مرجع پل شده، چیزی بیش از جدا کردن جداول نیست. یعنی تبدیل یک نوع جداول به دیگری از طریق طبقه بندی نشان داده شده در بالا به منظور جلوگیری از افزونگی داده ها - اینگونه می توان عادی سازی را تعریف کرد (یکی از گزینه های تعریف).

مثلا. اجازه دهید پایگاه داده ای وجود داشته باشد که در آن تنها عملیات اصلاح داده ها یک اضافه باشد. در این حالت، هر بار که هر ویژگی فردی را تغییر می‌دهید، بقیه مقادیر مشخصه را در تاپل دیگری «کپی» می‌کنید، بی‌اثر می‌شود. در این مورد، از NULL یا ایجاد یک مرجع استاتیک-دینامیک استفاده می‌شود، که در آن تعدادی از ویژگی‌های معنایی یکسان یا یک ویژگی توصیف می‌شوند و تنها کلید خارجی با کلید اصلی دنباله تکرار می‌شود. از همین روش می توان در طرح سنتی اصلاح داده ها با به روز رسانی و حذف داده ها استفاده کرد.

نتیجه

این طبقه بندی توسط من بر اساس مشاهدات در طراحی پایگاه داده ها و همچنین بر اساس تئوری خوانده شده در مورد طراحی در DBMS رابطه ای ایجاد شده است. به دوستان و آشنایانم که در رشته "پایگاه های اطلاعاتی" مطالعه می کنم و به طراحی پایگاه داده می پردازم و برای من این طبقه بندی به طور جدی "زندگی" را ساده کرده است و در بسیاری از مواقع این امکان را فراهم کرده است که از قبل مناسب ترین را انتخاب کنم و همانطور که بعداً مشخص شد. ، دید صحیحجداول برای ذخیره داده های خاص در آن.

طبقه بندی را می توان با تقسیم بندی گسترش داد گونه های موجوددر آن به زیرگونه ها (شاید حتی با افزودن گونه های جدید). همچنین، این طبقه بندی نشان داده است که در برخی شرایط بهتر است از این یا آن نوع جداول استفاده نشود. بهتر است از انواع جداول این طبقه بندی کمتر استفاده شود (کتاب های مرجع پویا). و سعی کنید برخی را با برخی دیگر جایگزین کنید (کتاب های مرجع-بسته ها با بسته ها).

امیدوارم این طبقه بندی در تسلط بر رشته "پایگاه های داده" و هنگام طراحی پایگاه های داده در DBMS رابطه ای به دیگران کمک کند.

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

مراحل اصلی طراحی پایگاه داده عبارتند از:

· تعیین هدف از ایجاد پایگاه داده.

· تعریف جداولی که پایگاه داده باید حاوی آنها باشد.

· تعریف فیلدهای مورد نیاز در جدول.

تعریف فیلدها با ارزش های منحصر به فرددر هر ورودی؛

· تعریف روابط بین جداول.

تعیین هدف از ایجاد پایگاه داده

اولین گام در طراحی پایگاه داده، تعریف هدف پایگاه داده، نحوه استفاده از آن و اطلاعاتی است که باید در آن وجود داشته باشد. با دانستن این موضوع، می توانید تعیین کنید که چه اطلاعاتی در جداول و فیلدهای جدول ذخیره می شود. پایگاه داده باید الزامات کسانی را که مستقیماً با آن کار می کنند برآورده کند. برای انجام این کار، شما باید موضوعاتی را که پایگاه داده باید پوشش دهد، گزارش هایی که باید صادر کند، و اسنادی را که باید ارائه کند، تعیین کنید. در حال حاضربرای نوشتن داده ها، مقایسه استفاده می شود پایگاه در حال ایجادداده ها با یک پایگاه داده خوب طراحی شده مانند آن. هدف این بانک اطلاعاتی به دست آوردن هرچه بیشتر اطلاعات در مورد مشتری، یعنی نام خانوادگی، نام، نام خانوادگی، آدرس، شماره تلفن و همچنین خدماتی است که باید برای این مشتری انجام شود.

تعیین جداولی که پایگاه داده باید حاوی آنها باشد

تعیین جداول مورد نیاز در پایگاه داده می تواند سخت ترین بخش فرآیند طراحی پایگاه داده باشد، زیرا نتایجی که پایگاه داده باید تولید کند گزارش ها، فرم ها و غیره است. - همیشه تصویر کاملی از ساختار جداولی که توسط آنها ایجاد شده اند ارائه ندهید. برای طراحی جداول خود نیازی به استفاده از Microsoft Access ندارید. بهتر است ابتدا ساختار را روی کاغذ طراحی کنید. هنگام توسعه جداول، توصیه می شود که از اصول اساسی زیر راهنمایی شود: 1) اطلاعات نباید در یک جدول یا بین جداول تکرار شوند. در این راستا جداول در پایه رابطه ایداده ها با جداول در برنامه هایی که با جداول در کار می کنند متفاوت است قالب متنمانند ویراستاران صفحات گسترده... داده های ذخیره شده فقط در یک جدول فقط در آن جدول به روز می شوند. این کار کارآمدتر است و علاوه بر این، امکان تکرار رکوردهای حاوی اطلاعات مختلف را از بین می برد. به عنوان مثال کافی است آدرس و شماره تلفن هر مشتری را یک بار در یک جدول ذخیره کنید 2) هر جدول فقط در مورد یک موضوع اطلاعات داشته باشد. هنگامی که هر جدول فقط حاوی اطلاعاتی در مورد یک موضوع است، می توانید با اطلاعات مربوط به هر موضوع مستقل از موضوعات دیگر کار کنید. به عنوان مثال، آدرس یک مشتری جدا از سفارشات آن مشتری نگه داشته می شود، که باعث می شود با حفظ اطلاعات مشتری، یک درخواست حذف شود. این پایگاه شامل هفت جدول سازمان مسکن، ساختمان مسکونی، آپارتمان، مستاجران، اطلاعات مستاجران، خدمات، اطلاعات خدمات انجام شده می باشد.

تعیین فیلدهای مورد نیاز در جدول

هر جدول حاوی اطلاعاتی در مورد یک موضوع خاص است و هر فیلد در جدول حاوی یک واقعیت خاص در مورد موضوع جدول است. به عنوان مثال، جدول "ساکنان" شامل فیلدهای نام خانوادگی، نام، نام خانوادگی و یک واقعیت خاص است. شخص خاصبه عنوان مثال، ایوانف ایوان ایوانوویچ.

هنگام جمع آوری فیلدهای هر جدول، اصول اساسی زیر باید در نظر گرفته شود:

· هر فیلد باید با موضوع جدول مرتبط باشد.

جدول باید شامل همه باشد اطلاعات لازم;

· داده ها باید به کوچکترین واحدهای منطقی تقسیم شوند.

تعریف فیلدهایی با مقادیر منحصر به فرد در هر رکورد

برای پیوند دادن اطلاعات ذخیره شده در Microsoft Access جداول مختلف- برای مثال، برای پیوند دادن یک افسر گذرنامه با همه مشتریانش - هر جدول پایگاه داده باید دارای فیلدها یا مجموعه ای از فیلدها باشد که به طور منحصر به فرد هر رکورد را شناسایی کند. چنین فیلد یا مجموعه ای از فیلدها کلید اولیه نامیده می شود. به عنوان مثال، جدول «سازمان مسکن» با یک رابطه «یک به چند» به جدول «ساختمان مسکونی» مرتبط است؛ بنابراین، جدول «ساختمان مسکونی» دارای کلید ثانویه «شماره سازمان» و کلید اولیه «خانه» است. عدد".

تعریف روابط بین جداول

بعد از اینکه اطلاعات را به جداول تقسیم کردید و فیلدهای کلیدی را شناسایی کردید، باید راهی را انتخاب کنید که در آن Microsoft Access اطلاعات مرتبط را دوباره ادغام کند. برای این کار باید روابط بین جداول پایه را تعریف کنید داده های مایکروسافتدسترسی داشته باشید. اتصالات وجود دارد: یک به بسیاری، بسیاری به بسیاری (به ندرت استفاده می شود).

این فصل یک جدول داده را مورد بحث قرار می دهد که یک آرایه را در نتیجه یک تابع ایجاد می کند جدول(این تابع را نمی توان به صورت دستی در سلول ها وارد کرد). جدول داده ها راهی سریع و آسان برای انجام تجزیه و تحلیل what-if برای محاسبات پیچیده مبتنی بر فرمول مرتبط با یکدیگر است. این تابع به شما امکان می دهد یک یا دو فرمول ورودی را تغییر دهید و نتایج را نشان دهید. فصل‌ها و قبلاً نمونه‌هایی از جداول داده‌ای که در ارتباط با توابع پایگاه داده استفاده شده‌اند ارائه کرده‌اند.

یادداشت را در قالب یا نمونه هایی در قالب دانلود کنید

تجزیه و تحلیل What-If بر اساس یک جدول تک متغیری

در شکل 21.1 در سلول B6 از تابع PMT استفاده شده است که به طور غیر مستقیم به مقدار سلول B2 بستگی دارد. اگر نرخ سالانه را تغییر دهید، PMT مقدار را در سلول B6 به روز می کند. هدف این است که به طور همزمان ببینیم که چگونه پرداخت ماهانه با پنج نرخ سالانه متفاوت تغییر خواهد کرد. در حالی که این کار را می توان با نوشتن یک فرمول انجام داد، تابع Table به دو دلیل می تواند مفید باشد:

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

برای ایجاد جدول داده:

1. سرفصل های A9: B9 را ایجاد کنید. در سلول B10 فرمول = B6 را وارد کنید. در سلول های A11: A15، مقادیر نرخ سالانه را برای تجزیه و تحلیل وارد کنید. محدوده A10: B15 را برجسته کنید.
2. از طریق منو بروید داده ها –> چه می شود اگر تجزیه و تحلیل –> جدول داده هابرای باز کردن گفتگو جدول داده ها، یا با فشار دادن و نگه داشتن کلید Alt، Y، Y، T را به ترتیب فشار دهید (پس از فشار دادن Alt، نکات در منو ظاهر می شود).
3. از آنجایی که شما در حال تجزیه و تحلیل تأثیر نرخ سالانه هستید، لطفاً پیوندی به آن در فیلد قرار دهید مقدار را خط به خط در جایگزین کنید(شکل 21.2). تو حرف بزن جدول داده ها، مقدار سلول B2 را در فرآیند محاسبه PMT جایگزین کنید و به جای آن مقادیر را از محدوده A11: A15 در فرمول جایگزین کنید.
4. روی OK کلیک کنید.

برنج. 21.2. پنجره گفتگو جدول داده ها

اگر محدوده B11: B15 را انتخاب کنید و به نوار فرمول نگاه کنید، جدول فرمول آرایه ای را با ارجاع به سلول B2 مشاهده خواهید کرد. تابع Table را نمی توان از صفحه کلید وارد کرد. هنگام استفاده از کادر محاوره ای به طور خودکار تولید می شود جدول داده ها.

برنج. 21.3. جدول تابع را فقط می توان با استفاده از کادر محاوره ای وارد کرد جدول داده ها

در شکل 21.4 سلول در محدوده E3: I3 حاوی فرمول های مختلفی است که به طور مستقیم یا غیرمستقیم به تعداد قطعات فروخته شده (در سلول B3) اشاره دارد. استفاده كردن جدول داده هامی توانید تجزیه و تحلیل what-if را بر روی پنج فرمول انجام دهید. علاوه بر این، همه آنها بر اساس یک متغیر است که در محدوده D4: D12 قرار دارد.

برنج. 21.4. یک متغیر جداول داده هامی تواند بر روی چندین فرمول کار کند. برای بزرگ شدن تصویر روی آن کلیک کنید کلیک راستماوس را انتخاب کنید تصویر را در یک برگه جدید باز کنید

دو متغیر در جدول داده ها

در مثال زیر، وظیفه یافتن حداقل مقدار بر اساس دو معیار است. برای این مورد استفاده می شود جدول داده هابر اساس دو متغیر (شکل 21.5). فرمول را در سمت چپ قرار دهید گوشه بالایی جداول داده ها(در مثال ما - در سلول F8)، و customize را در کادر محاوره ای وارد کنید جدول داده هاهمانطور که در شکل نشان داده شده است. 21.5.

برنج. 21.5. جدول داده هابا دو متغیر

شما قبلاً نمونه دوم (شکل 21.6) را در اینجا مشاهده کردید. از فرمول آرایه ای استفاده می کرد. به عنوان مثال، در سلول F9: = INDEX ($ C $ 2: $ C $ 15; SEARCH ($ E9 & F $ 8; $ A $ 2: $ A $ 15 & $ B $ 2: $ B $ 15; 0 )). مبتنی بر راه حل جداول داده هاراحت تر و سریع تر

برنج. 21.6. استفاده جداول داده ها، به عنوان جایگزینی برای VLOOKUP در دو پارامتر

یک نکته پایانی در جداول داده ها: گزینه ای وجود دارد که به شما امکان می دهد غیرفعال کنید به روز رسانی خودکار جداول داده ها، در حالی که سایر فرمول ها به طور خودکار مجدداً محاسبه می شوند. اگر فایل شما "آهسته" می شود، از طریق منو بروید فایل –> مولفه های، به برگه بروید فرمول ها، و گزینه را انتخاب کنید به طور خودکار، به جز جداول داده(شکل 21.7). هر زمان که بخواهید محاسبات را به روز کنید جدول داده ها، F9 را فشار دهید.

برنج. 21.7. غیرفعال کردن محاسبه خودکار جداول داده ها

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

در این مقاله

اصطلاحات پایگاه داده

V مایکروسافت آفیس Access 2007 داده ها را سازماندهی می کند جداول- مجموعه ای از ردیف ها و ستون ها، شبیه به مقالات یک حسابدار یا کتاب مایکروسافت آفیس اکسل 2007. پایه سادهداده ها می توانند فقط از یک جدول تشکیل شوند. اکثر پایگاه های داده شامل چندین جدول هستند. به عنوان مثال، یک جدول ممکن است اطلاعات محصول را ذخیره کند، جدول دوم ممکن است اطلاعات سفارش را ذخیره کند و جدول سوم ممکن است اطلاعات مشتری را ذخیره کند.

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

ساختار صحیح پایگاه داده

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

ساختار صحیحپایگاه داده به این معنی است:

• توزیع داده ها بر اساس جداول موضوعی به منظور کاهش میزان داده های تکراری.
• داده هایی را که برای ترکیب اطلاعات موجود در جداول ضروری است به Access اضافه کنید.
• توانایی حفظ و ردیابی صحت و یکپارچگی داده ها؛
• رعایت الزامات پردازش داده و گزارش.

فرآیند توسعه

فرآیند توسعه پایگاه داده شامل مراحل زیر است.

• تعیین هدف از ایجاد پایگاه داده

این به شما امکان می دهد برای مراحل بعدی آماده شوید.

• یافتن و سازماندهی داده های مورد نیاز

تمام داده هایی که باید در پایگاه داده ذخیره شوند باید جمع آوری شوند، مانند نام محصول و شماره سفارش.

• توزیع داده ها در جداول

اقلام داده را در گروه ها یا موضوعاتی مانند "محصولات" یا "سفارش ها" سازماندهی کنید. برای هر موضوع جدولی ایجاد می شود.

• تبدیل آیتم ها به ستون

تعیین کنید که چه داده هایی را می خواهید در هر جدول ذخیره کنید. هر مورد داده در یک فیلد جداگانه وارد می شود و به یک ستون در جدول تبدیل می شود. برای مثال، جدول Employees ممکن است حاوی فیلدهایی مانند نام خانوادگی و تاریخ استخدام باشد.

• تنظیم کلیدهای اولیه

کلیدهای اصلی جداول را انتخاب کنید. کلید اصلی - ستونی که به طور منحصر به فرد هر رکورد، مانند یک محصول یا کد سفارش را مشخص می کند.

• ایجاد روابط بین جداول

همه جداول را تجزیه و تحلیل کنید و تعیین کنید که چگونه داده های یک جدول با داده های جداول دیگر مرتبط است. فیلدها را به جداول اضافه کنید یا جداول جدید ایجاد کنید تا روابط لازم ایجاد شود.

• بهبود ساختار

ساختار پایگاه داده خود را برای وجود خطا بررسی کنید. جداول ایجاد کنید و چند نمونه رکورد داده اضافه کنید. نتایج خود را تجزیه و تحلیل کنید در صورت نیاز ساختار را اصلاح کنید.

• اعمال قوانین عادی سازی

قوانین عادی سازی را برای بررسی درستی ساختار جداول اعمال کنید. در صورت نیاز جداول را اصلاح کنید.

تعیین هدف از ایجاد پایگاه داده

توصیه می شود هدف ایجاد پایگاه داده را روی کاغذ یادداشت کنید: وظایف، روش های استفاده و لیستی از کاربران. برای یک پایگاه داده کوچک برای کار از خانه، می توانید موارد زیر را تعریف کنید هدف ساده: « پایگاه داده مشتریان حاوی اطلاعاتی در مورد مشتریان است و برای ارسال پیام استفاده می شود پست الکترونیکو گزارش می دهد. هنگام ایجاد یک پایگاه داده پیچیده تر برای تعداد زیادی از کاربران، به عنوان مثال در یک سازمان، شرح هدف ممکن است شامل چندین پاراگراف باشد. باید زمان و روش استفاده از پایگاه داده را مشخص کنید توسط کاربران مختلف... وظیفه اصلی آهنگسازی است توصیف همراه با جزئیاتهدف از ایجاد یک پایگاه داده است تا بتوان در طول فرآیند طراحی به آن مراجعه کرد. وجود توضیحات به شما امکان می دهد تا اهداف تعیین شده را در فرآیند تصمیم گیری دنبال کنید.

یافتن و سازماندهی داده های مورد نیاز

فرآیند یافتن و سازماندهی اطلاعات مورد نیاز باید با ثبت اطلاعات موجود آغاز شود. به عنوان مثال، می توانید سفارشات را از دفتر کل ثبت کنید یا اطلاعات مشتری را از یک کابینت بایگانی ذخیره کنید. جمع آوری کنید مدارک مورد نیازو فهرستی از انواع داده ها (مثلاً فهرستی از فیلدها در یک فرم) ایجاد کنید. اگر از لوازم التحریر استفاده نمی کنید، تصور کنید که می خواهید یک نوشت افزار برای ثبت اطلاعات مشتری بسازید. چه داده هایی را می خواهید ثبت کنید؟ چه فیلدهایی را باید پر کنید؟ تعريف كردن عناصر مورد نیازو آنها را فهرست کنید. فرض کنید اطلاعات مشتری در یک کابینت بایگانی ذخیره می شود. تجزیه و تحلیل کارت ها نشان می دهد که آنها حاوی اطلاعاتی مانند نام مشتری، آدرس، شهر، ایالت، کد پستی و شماره تلفن هستند. هر یک از این عناصر می توانند به یک ستون در یک جدول تبدیل شوند.

هنگام تهیه یک لیست، لازم نیست تلاش کنید تا در اولین بار ظاهری کامل به آن بدهید. همه باید ثبت شود گزینه های ممکن... اگر پایگاه داده برای چندین کاربر در نظر گرفته شده است، پیشنهادات آنها را از آنها بخواهید. لیست را می توان بعداً اصلاح کرد.

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

با تعریف ساختار گزارش‌ها و ارسال‌ها، می‌توانید مواردی را که می‌خواهید در پایگاه داده قرار دهید شناسایی کنید. فرض کنید می خواهید به مشتریان امکان اشتراک یا لغو اشتراک در یک خبرنامه معمولی را بدهید و بتوانید لیستی از مشترکین را چاپ کنید. برای ثبت این اطلاعات در جدول مشتریان، ستونی برای ارسال پیام های ایمیل اضافه کنید. در این قسمت می توانید برای هر مشتری گزینه Yes یا No را انتخاب کنید.

برای ارسال پیام‌های ایمیل به مشتریان، یک داده دیگر باید ثبت شود. اگر مشتری با دریافت پیام های ایمیل موافقت کند، باید آدرس ایمیل خود را ثبت کند. بنابراین، شما باید یک آدرس ایمیل برای هر مشتری ذخیره کنید.

نمونه سازی اولیه هر گزارش یا لیست مشتری برای چاپ و تعیین اینکه چه اقلام داده ای برای تولید آنها لازم است، راحت است. به عنوان مثال، تجزیه و تحلیل یک نامه چندین عنصر را آشکار می کند. اگر می خواهید یک تبریک در نامه بگنجانید - برای مثال، رشته "d." یا "خانم" - باید مورد مربوطه را ایجاد کنید. علاوه بر این، نامه معمولاً با عبارت استاندارد «آقای اگوروف عزیز» شروع می شود تا «جناب آقای ولادیمیر اگوروف». بنابراین، نام خانوادگی باید جدا از نام کوچک نگهداری شود.

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

سوالاتی را که می خواهید با استفاده از پایگاه داده به آنها پاسخ دهید، فهرست کنید. به عنوان مثال، حجم فروش یک محصول در ماه گذشته چقدر بوده است؟ مشتریان امیدوار کننده کجا هستند؟ چه کسی پرفروش ترین محصول را عرضه می کند؟ فهرست کنید سوالات احتمالیبه شما اجازه می دهد تا آیتم های داده اضافی را برای رکورد تعریف کنید.

پس از جمع آوری داده ها، می توانید به مرحله بعدی بروید.

توزیع داده ها در جداول

برای توزیع داده ها در جداول، گروه ها یا موضوعات اصلی را برجسته کنید. به عنوان مثال، پس از جستجو و سازماندهی داده ها برای پایگاه داده فروش محصول، لیست زیر قابل جمع آوری است:

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

هنگامی که برای اولین بار به فهرست اولیه اقلام نگاه می کنید، ممکن است فکر کنید که منطقی تر است که به جای ایجاد چهار جدول، همانطور که در مثال قبلی نشان داده شده است، همه موارد را در یک جدول قرار دهید. این بخش توضیح می دهد که چرا این رویکرد بی اثر است. جدول در تصویر را بررسی کنید.

V در این موردهر خط حاوی داده هایی در مورد محصولات و تامین کنندگان است. از آنجایی که یک تامین کننده تامین می کند محصولات مختلف، نام و آدرس او باید دوباره وارد شود. در عین حال، فضای دیسک به طور ناکارآمد استفاده می شود. راه حل هوشمندتر این است که اطلاعات تامین کننده را در یک جدول تامین کننده جداگانه ذخیره کنید و آن جدول را به جدول محصول پیوند دهید.

مشکل دوم در مورد چنین ساختار پایگاه داده زمانی ایجاد می شود که نیاز به تغییر اطلاعات مربوط به تامین کننده باشد. فرض کنید می خواهید آدرس یک فروشنده را تغییر دهید. از آنجایی که خطوط زیادی برای تامین کننده وجود دارد، کاربر می تواند برخی از آنها را نادیده بگیرد. همچنین می توانید این مشکل را با ذخیره آدرس فروشنده در یک مکان حل کنید.

هنگام طراحی یک پایگاه داده، باید تلاش کنید تا هر مورد از داده ها را یک بار ذخیره کنید. اگر داده ها تکراری هستند (مثلاً آدرس یک تامین کننده جداگانه)، آن را در یک جدول جداگانه قرار دهید.

در نهایت، فرض کنید که Coho Winery تنها یک محصول ارسال می کند و شما می خواهید آن را حذف نصب کنید، در حالی که اطلاعات نام فروشنده و آدرس را حفظ می کنید. چگونه می توانم یک رکورد محصول را با حفظ جزئیات تامین کننده حذف کنم؟ غیر ممکنه. از آنجایی که هر ردیف حاوی داده های محصول و همچنین داده های تامین کننده است، حذف این داده ها به طور جداگانه از یکدیگر امکان پذیر نیست. برای جداسازی این داده ها، باید دو جدول، یکی برای اطلاعات محصول و دیگری برای اطلاعات تامین کننده ایجاد کنید. در این صورت، حذف رکورد محصول، داده های تامین کننده را حذف نمی کند.

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

تبدیل آیتم ها به ستون

برای تعیین ستون های جدول، باید تصمیم بگیرید که چه اطلاعاتی را می خواهید برای جدول ردیابی کنید. به عنوان مثال، می توانید ستون های نام، آدرس، شهر / ایالت / کد پستی، ارسال ایمیل، پرونده و آدرس ایمیل را در جدول مشتری قرار دهید. همه سطرها شامل مجموعه ستون های یکسانی هستند، بنابراین می توانید اطلاعات مناسب را برای هر ردیف ذخیره کنید. به عنوان مثال، ستون "آدرس" حاوی آدرس های مشتریان است. هر رکورد حاوی اطلاعات فقط یک مشتری است و فیلد آدرس حاوی آدرس آن مشتری است.

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

همچنین باید مشخص کند که چه نوع داده ای در پایگاه داده ذخیره می شود: ملی یا بین المللی. به عنوان مثال، اگر قصد دارید آدرس‌های بین‌المللی را در پایگاه داده ذخیره کنید، بهتر است از ستون Region به جای Country استفاده کنید، زیرا از این ستون می‌توان برای تعیین مناطق داخل کشور خود و مناطق در کشورهای دیگر استفاده کرد. به همین ترتیب امکان ذخیره سازی در قسمت کد پستی نیز وجود خواهد داشت کدهای پستیکشورهای مختلف.

لیست زیر نکاتی را برای ایجاد ستون ها ارائه می دهد.

• داده های محاسبه شده را در جدول خود وارد نکنید

نتایج محاسبات نباید در جداول ذخیره شود. در عوض، هر زمان که بخواهید به نتیجه برسید، می توانید محاسبات را در Access انجام دهید. برای مثال، فرض کنید گزارش سفارش محصولات، مجموع فرعی محصولات سفارش داده شده در هر دسته را نمایش می دهد. با این حال، جدول شامل ستونی برای جمع های فرعی نیست. در عوض، جدول شامل ستونی برای محصولات سفارش داده شده است که مقدار هر محصول را ذخیره می کند. با اینها دسترسی به داده هاهر بار که یک گزارش چاپ می شود، جمع های فرعی را محاسبه می کند. خود مجموع های فرعی در جدول ذخیره نمی شوند.

• اطلاعات را به حداقل اجزای منطقی تقسیم کنید

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

پس از ایجاد ستون در جداول، می توانید یک کلید اصلی برای هر جدول انتخاب کنید.

تنظیم کلیدهای اولیه

هر جدول باید شامل یک ستون یا مجموعه ای از ستون ها باشد تا هر ردیف در جدول به طور منحصر به فرد شناسایی شود. به عنوان یک قاعده، برای این اهداف، منحصر به فرد است یک شماره شناساییبه عنوان مثال کد کارمند یا شماره سریال... در پایگاه داده، چنین اطلاعاتی نامیده می شود کلید اصلیجداول در Access، از کلیدهای اولیه برای پیوند دادن سریع داده ها از چندین جدول و نمایش آن به کاربر استفاده می شود.

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

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

مقدار کلید اصلی نباید تغییر کند. در یک پایگاه داده با چندین جدول، کلید اصلی یک جدول می تواند به عنوان مرجع در جداول دیگر استفاده شود. اگر کلید اصلی تغییر کند، این تغییر باید برای همه مراجع به آن کلید اعمال شود. با استفاده از کلید اصلی با مقدار ثابت، احتمال عدم همگام شدن با سایر جداول کمتر است.

اغلب، یک منحصر به فرد دلخواه به عنوان کلید اصلی استفاده می شود. مقدار عددی... به عنوان مثال، شما می توانید یک شماره سفارش منحصر به فرد به هر سفارش اختصاص دهید تا سفارش را به طور منحصر به فرد شناسایی کنید. این عدد قابل تغییر نیست.

اگر نمی توانید یک ستون یا مجموعه ای از ستون ها را برای استفاده به عنوان کلید اصلی انتخاب کنید، می توانید از ستونی با نوع داده Counter استفاده کنید. هنگامی که از چنین ستونی استفاده می کنید، Access به طور خودکار مقادیری را اختصاص می دهد. این کد حاوی هیچ اطلاعاتی نیست. هیچ توضیحی از رشته ای که نشان می دهد ندارد. کدهای خالی برای استفاده به عنوان کلید اصلی ایده آل هستند زیرا تغییر نمی کنند. کلید اصلی که حاوی اطلاعات رشته واقعی است، مانند شماره تلفن یا نام مشتری، بیشتر مستعد تغییر است زیرا ممکن است اطلاعات واقعی تغییر کند.

ستون شمارنده یک کلید اولیه مناسب است. کدهای محصول هرگز مطابقت ندارند.

در برخی موارد، استفاده از دو یا چند فیلد به عنوان کلید اصلی جدول الزامی است. برای مثال، برای جدول جزئیات سفارش که اقلام خطی را برای سفارش‌ها ذخیره می‌کند، می‌توانید از دو ستون در کلید اصلی استفاده کنید: کد سفارش و کد محصول. یک کلید اولیه چند ستونی، کلید اولیه ترکیبی نامیده می شود.

در پایگاه داده فروش، می توانید یک ستون شمارنده برای کلید اصلی همه جداول ایجاد کنید: شناسه آیتم برای جدول آیتم، شناسه سفارش برای جدول سفارشات، شناسه مشتری برای جدول مشتری و شناسه فروشنده برای جدول فروشنده.

ایجاد روابط بین جداول

پس از توزیع داده ها در جداول، باید بتوانید آنها را ترکیب کنید. به عنوان مثال، فرم زیر شامل اطلاعاتی از چندین جدول است.

این فرم حاوی داده هایی از جدول مشتری است،

کارمندان،

سفارشات،

محصولات

و اطلاعات سفارش

Access یک سیستم مدیریت پایگاه داده رابطه ای است. در یک پایگاه داده رابطه ای، اطلاعات در جداول جداگانه و به صورت موضوعی سازماندهی شده توزیع می شود. پیوند بین جداول برای ترکیب داده ها استفاده می شود.

یک رابطه یک به چند ایجاد کنید

در نظر گرفتن مثال بعدی: پایگاه داده سفارش محصول شامل جداول تامین کنندگان و محصولات می باشد. یک تامین کننده می تواند هر تعداد محصول را عرضه کند. بنابراین، برای هر فروشنده از جدول فروشنده، جدول محصول ممکن است شامل باشد تعداد زیادی ازمحصولات بنابراین، رابطه بین جدول فروشنده و جدول محصول یک رابطه یک به چند است.

برای ایجاد رابطه یک به چند در ساختار پایگاه داده، کلید اصلی یک طرفه را به عنوان ستون اضافی به جدول چند طرفه اضافه کنید. V این مثالباید ستون کد فروشنده را از جدول فروشنده به جدول محصول اضافه کنید. سپس اکسس می تواند از کد فروشنده از جدول محصول برای یافتن فروشنده برای هر محصول استفاده کند.

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

اساس پیوند جداول، ترکیب کلیدهای اصلی و خارجی به صورت جفت است. اگر نمی توانید جداول را با یک ستون مشترک تعریف کنید، ایجاد یک رابطه یک به چند تضمین می کند که یک ستون مشترک برای دو جدول مورد نیاز است.

یک رابطه چند به چند ایجاد کنید

بیایید رابطه بین جداول محصولات و سفارشات را در نظر بگیریم.

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

موضوعات دو جدول - سفارشات و محصولات - با یک رابطه چند به چند مرتبط هستند. این مشکل است. تصور کنید چه اتفاقی می افتد اگر با افزودن یک فیلد کد محصول به جدول سفارش، رابطه ای بین دو جدول ایجاد کنید. برای اینکه یک سفارش حاوی چندین محصول باشد، هر سفارش در جدول باید شامل چندین ورودی باشد. در این حالت، اطلاعات سفارش باید در هر خط از سفارش تکرار شود، که می تواند منجر به ساختار جدول ناکارآمد و داده های نادرست شود. همین مشکل هنگام ایجاد یک فیلد با کد سفارش در جدول محصول ایجاد می شود - چندین رکورد برای هر محصول در جدول وجود دارد. چگونه این مسئله را می توان حل کرد؟

راه حل ایجاد یک جدول سوم پل زدن است که در آن رابطه چند به چند به دو رابطه یک به چند تقسیم می شود. کلیدهای اصلی دو جدول در جدول سوم قرار می گیرند. در نتیجه، تمام نمونه های رابطه در جدول سوم ذخیره می شوند.

هر ورودی در جدول جزئیات سفارش نشان دهنده است عنصر جداگانهخطوط سفارش کلید اصلی یک جدول از دو قسمت تشکیل شده است - کلیدهای خارجی جداول سفارش و محصول. استفاده از فیلد با کد دستوری برای کلید اصلی این جدول امکان پذیر نیست، زیرا یک سفارش می تواند حاوی عناصر ردیف زیادی باشد. کد سفارش برای هر خط تکرار می شود، بنابراین این فیلد حاوی مقادیر منحصر به فرد نیست. همچنین استفاده از فیلد با کد محصول امکان پذیر نیست، زیرا یک محصول می تواند در چندین سفارش گنجانده شود. با این حال، استفاده از دو فیلد به شما امکان می دهد برای هر رکورد یک مقدار منحصر به فرد دریافت کنید.

در پایگاه فروش محصولات جداول سفارشات و محصولات ارتباط مستقیمی با هم ندارند. آنها به طور غیر مستقیم از طریق جدول جزئیات سفارش پیوند داده شده اند. رابطه چند به چند بین سفارشات و محصولات در پایگاه داده با دو رابطه یک به چند نشان داده می شود:

• جداول اطلاعات سفارش و سفارش در یک رابطه یک به چند به هم مرتبط هستند. هر سفارش شامل چندین مورد خط است، اما هر مورد فقط با یک سفارش مرتبط است.
• جداول اطلاعات محصول و سفارش در یک رابطه یک به چند به هم مرتبط هستند. هر محصول را می توان با چندین آیتم ردیف مرتبط کرد، اما هر مورد تنها با یک محصول مرتبط است.

در جدول جزئیات سفارش، می توانید محصولات را برای یک سفارش تعریف کنید. شما همچنین می توانید سفارشات یک محصول خاص را تعریف کنید.

پس از ایجاد جدول جزئیات سفارش، لیست جداول و فیلدها ممکن است به شکل زیر باشد:

ایجاد رابطه یک به یک

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

اگر می خواهید در پایگاه داده خود یک رابطه یک به یک ایجاد کنید، داده ها را در یک جدول واحد ادغام کنید. اگر این گزینه برای مثال به دلیل خالی بودن فیلدها قابل قبول نیست، از لیست زیر برای تعریف رابطه در ساختار پایگاه داده استفاده کنید.

• اگر جداول با یک موضوع مرتبط باشند، می توان با استفاده از یک کلید اولیه مشترک، رابطه ایجاد کرد.
• اگر موضوع و کلیدهای اصلی جداول متفاوت است، باید هر یک از جداول را انتخاب کنید و کلید اصلی آن را به عنوان کلید خارجی در جدول دیگری وارد کنید.

تعریف روابط بین جداول به اطمینان از درستی جداول و ستون ها کمک می کند. اگر رابطه یک به یک یا یک به چند وجود دارد، جداول باید حاوی باشند ستون های مشترک... اگر رابطه چند به چند دارید، جدول سوم لازم است.

بهبود ساختار

پس از ایجاد جداول، فیلدها و روابط لازم، باید جداول را با داده های نمونه پر کنید و با آنها عملیات مختلفی انجام دهید: ایجاد پرس و جو، افزودن رکوردهای جدید و غیره. مشکلات احتمالی- برای مثال، ممکن است لازم باشد یک ستون اضافی اضافه کنید یا یک جدول را به دو تقسیم کنید تا از داده های تکراری جلوگیری کنید.

بررسی کنید که آیا می توان از پایگاه داده برای دریافت پاسخ استفاده کرد سوالات لازم... پیش نویس فرم ها و گزارش ها را ایجاد کنید و مطمئن شوید که اطلاعات مورد نظر شما را نمایش می دهند. پایگاه داده را برای داده های تکراری بررسی کنید و در صورت لزوم این داده ها را حذف کنید.

هنگامی که کار با پایگاه داده خود را شروع می کنید، می توانید زمینه هایی را برای بهبود ساختار آن شناسایی کنید. می توانید به نکات زیر توجه کنید:

• ستون های مورد نیاز وجود ندارد. اگر تعدادی از ستون‌ها گم شده‌اند، باید تعیین کنید کدام یک از آنها جداول موجودمی توانید داده ها را اضافه کنید اگر داده ها به موضوع دیگری مربوط می شود، ممکن است لازم باشد جدول اضافی... برای هر مورد از داده هایی که می خواهید ردیابی کنید یک ستون ایجاد کنید. اگر با محاسبات نمی توان داده ها را از ستون های دیگر بازیابی کرد، ممکن است ستون جدیدی مورد نیاز باشد.
• وجود ستون هایی که داده های آنها را می توان از فیلدهای موجود با محاسبات به دست آورد. اگر داده ها را می توان از ستون های دیگر محاسبه کرد - برای مثال، قیمت تخفیف را می توان بر اساس قیمت خرده فروشی محاسبه کرد - توصیه می کنیم از استفاده از ستون های اضافی خودداری کنید.
• وجود داده های تکراری در جداول. در این حالت، شما باید جدول را به دو جدول تقسیم کنید و آنها را در یک رابطه یک به چند پیوند دهید.
• در دسترس بودن جداول با مقدار زیادزمینه های، تعداد محدودیرکوردها و فیلدهای خالی در رکوردهای فردی... در این حالت ممکن است نیاز به تغییر ساختار جدول برای کاهش تعداد فیلدها و افزایش تعداد رکوردها باشد.
• شکستن هر قطعه از داده ها به اجزای حداقل. اگر می خواهید از یک آیتم داده برای گزارش، مرتب سازی، جستجو یا محاسبات استفاده کنید، باید در یک ستون جداگانه قرار گیرد.
• وجود در ستون داده های مربوط به موضوع جدول. اگر ستون حاوی داده هایی است که به موضوع جدول مربوط نمی شود، باید در جدول دیگری قرار گیرد.
• روابط بین جداول نشان داده شده توسط فیلدهای مشترک یا جدول سوم. ستون های مشترک برای ایجاد روابط یک به یک و یک به چند مورد نیاز است. یک جدول سوم برای ایجاد رابطه چند به چند مورد نیاز است.

بهبود ساختار جدول محصول

فرض کنید که تمام محصولات موجود در یک پایگاه داده را می توان به چند دسته کلی دسته بندی کرد، مانند نوشیدنی ها، چاشنی ها یا محصولات ماهی. جدول محصول می تواند حاوی فیلدی باشد که دسته بندی محصول را نشان می دهد.

فرض کنید پس از تجزیه و تحلیل و بهبود ساختار پایگاه داده، تصمیم گرفته شد که نه تنها نام دسته محصول، بلکه توضیحات آن نیز ذخیره شود. اگر یک قسمت توضیحات دسته را به جدول محصول اضافه کنید، توضیحات باید برای هر محصول در یک دسته جداگانه تکرار شود و این تصمیم منطقی نیست.

یک رویکرد منطقی تر این است که دسته را به عنوان یک موضوع جداگانه برای ردیابی در پایگاه داده تنظیم کنید، یک جدول جداگانه با کلید اصلی خود ایجاد کنید. سپس کلید اصلی جدول دسته بندی را می توان به عنوان کلید خارجی به جدول محصول اضافه کرد.

هنگام تجزیه و تحلیل ساختار جداول، باید گروه های تکراری را شناسایی کنید. فرض کنید جدول شامل ستون های زیر است:

• کد محصول
• کد محصول 1
• کد محصول 2
• کد محصول 3

در این حالت، محصولات گروه‌هایی از ستون‌های تکراری هستند که تنها با تعداد در نام ستون با یکدیگر تفاوت دارند. اگر ستون ها به این ترتیب شماره گذاری شوند، ساختار جدول باید اصلاح شود.

این ساختار دارای چندین معایب است. اول از همه، محدودیت بالایی برای تعداد محصولات وجود دارد. پس از گذشتن از این حد، به جدول اضافه کنید گروه جدیدستون‌ها، و انجام این کار دشوار است.

یکی دیگر از معایب این است که اگر تعداد محصولات برای یک فروشنده فردی کمتر از حداکثر باشد، برخی از ستون‌ها خالی خواهند بود. اما جدی ترین ایراد این ساختار، پیچیدگی بسیاری از کارها مانند مرتب سازی یا ایجاد نمایه روی جدول بر اساس کد یا نام محصول است.

اگر گروه های تکراری دارید، یک جدول را به دو قسمت تقسیم کنید. در مثال بالا بهتر است دو جدول یکی برای فروشندگان و دیگری برای محصولات ایجاد کنید و با استفاده از کد فروشنده آنها را پیوند دهید.

اعمال قوانین عادی سازی

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

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

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

اولین فرم معمولی

اولین فرم معمولیحاوی این قانون است که هر سلول در تقاطع یک ردیف و یک ستون در جدول باید حاوی یک مقدار باشد نه لیستی از مقادیر. به عنوان مثال، قسمت Price باید فقط یک مقدار قیمت داشته باشد. اگر سلولی در محل تلاقی یک سطر و یک ستون وجود داشته باشد، باید فقط یک مقدار داشته باشد.

فرم معمولی دوم

دومین شکل عادی مستلزم این است که هر ستون خارج از کلید باید به کل ستون کلید بستگی داشته باشد نه بخشی از آن. این قانون در صورتی اعمال می شود که کلید اصلی دارای چندین ستون باشد. فرض کنید جدولی با کلید اصلی ستون های شناسه سفارش و شناسه محصول حاوی ستون های زیر باشد:

• کد سفارش (کلید اصلی)
• کد محصول (کلید اصلی)
• نام محصول

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

فرم سوم عادی

سومین شکل عادی مستلزم آن است که ستون های غیر کلیدی نه تنها به کل کلید اصلی وابسته باشند، بلکه مستقل از یکدیگر باشند.

به عبارت دیگر، هر ستون بدون کلید فقط باید به کلید اصلی بستگی داشته باشد. فرض کنید جدول شامل ستون های زیر است:

• کد محصول (کلید اصلی)
• قیمت پیشنهادی خرده فروشی
• تخفیف

فرض کنید تخفیف بر اساس قیمت خرده فروشی پیشنهادی است. در این حالت، جدول الزامات سومین فرم رایج را برآورده نمی کند، زیرا ستون تخفیف بدون کلید به ستون غیر کلیدی دیگری (ستون قیمت خرده فروشی توصیه شده) بستگی دارد. الزام ستون ها به مستقل بودن از یکدیگر به این معنی است که تغییر هر ستون غیر کلیدی نباید بر ستون های دیگر تأثیر بگذارد. اما اگر ارزش ستون قیمت خرده‌فروشی تغییر کند، ارزش تخفیف بر این اساس تغییر می‌کند و این قانون را زیر پا می‌گذارد. بنابراین، در این حالت، ستون تخفیف باید به جدول دیگری منتقل شود که ستون قیمت خرده فروشی در آن کلید است.

اطلاعات اضافی

برای اطلاعات بیشتر در مورد طراحی پایگاه داده به کتاب های زیر مراجعه کنید.

• هرناندز، مایکل جی. طراحی پایگاه داده برای MereMortals: A Hands-On Guide to Design Database Relational, ویرایش دوم.ادیسون وسلی حرفه ای. 2003.
• فلمینگ، کندیس سی. فون هال، باربارا. کتابچه راهنمای طراحی پایگاه داده رابطه ای.ادیسون وسلی حرفه ای. 1989.
• ریوردان، ربکا ام. طراحی سیستم های پایگاه داده موثرادیسون وسلی حرفه ای. 2005.

برای Access 2007 و بالاتر اعمال می شود

هر جدول حاوی اطلاعاتی در مورد یک موضوع متفاوت است و هر فیلد در جدول حاوی اطلاعات جداگانه در مورد موضوع جدول است. به عنوان مثال، یک جدول با اطلاعات مشتری ممکن است حاوی فیلدهایی با نام شرکت، آدرس، شهر، کشور و شماره تلفن باشد. هنگام طراحی فیلدهای هر جدول، به خاطر داشته باشید:

هر فیلد باید با موضوع جدول مرتبط باشد.

جدول باید حاوی تمام اطلاعات لازم باشد.

اطلاعات باید به کوچکترین واحدهای منطقی تقسیم شوند (به عنوان مثال، قسمت نام و نام خانوادگی، نه فیلد نام عمومی).

4. تنظیم یک مقدار جداگانه برای هر فیلد

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

5. تعریف روابط بین جداول

پس از توزیع داده ها در جداول و تعریف فیلدهای کلیدی، باید طرحی را برای پیوند دادن داده ها در جداول مختلف انتخاب کنید. برای انجام این کار، باید روابط بین جداول را تعریف کنید.

6. به روز رسانی ساختار پایگاه داده

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

برای بررسی، باید چندین جدول ایجاد کنید، روابط بین آنها را مشخص کنید و چندین رکورد را در هر جدول وارد کنید، سپس ببینید آیا پایگاه داده مطابق با الزامات است. همچنین توصیه می‌شود فرم‌ها و گزارش‌های خروجی پیش‌نویس ایجاد کنید و بررسی کنید که آیا اطلاعات مورد نظر شما را ارائه می‌دهند یا خیر. علاوه بر این، لازم است تمام داده های تکراری احتمالی از جداول حذف شوند.

7. افزودن داده ها و ایجاد سایر اشیاء پایگاه داده

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

8. استفاده از ابزارهای تجزیه و تحلیل در مایکروسافت اکسس

دو ابزار در Microsoft Access برای بهبود طراحی پایگاه داده وجود دارد. جادوگر تجزیه و تحلیل جدول جدول را بررسی می کند، در صورت لزوم ساختار و روابط جدیدی را پیشنهاد می کند و همچنین آن را حذف می کند.

Performance Analyzer کل پایگاه داده را بررسی می کند، توصیه هایی برای بهبود آن ارائه می دهد و همچنین آنها را پیاده سازی می کند.

از آنجایی که بخش های مستقل برنامه توسعه می یابد، توصیه می شود آنها را به مشتری منتقل کنید تا عملکرد آنها را بررسی کرده و نظر خود را در مورد نیاز به ایجاد تغییرات خاص به دست آورید. پس از اینکه مشتری با عملکرد برنامه آشنا شد، تقریباً همیشه پیشنهادات اضافی برای بهبود دارد، مهم نیست که مطالعه اولیه پروژه چقدر دقیق باشد. کاربران اغلب متوجه می شوند که برخی از نکاتی که در مورد آنها به عنوان بسیار مهم و ضروری در فرآیند تنظیم وظایف صحبت کردند، واقعاً نقش مهمی در استفاده عملی از برنامه ندارند. شناسایی تغییرات ضروری در اوایل توسعه یک برنامه کاربردی می تواند زمان برای کار مجدد بعدی را به میزان قابل توجهی کاهش دهد.