جداول اولیه و ارائه شده ، جداول مبنا (base table) نامیده می شوند . جدولی که توسط بعضی از عبارات رابطه ای از این جداول مبنا بدست می آید ، جدول مشتق شده (driven) نامیده می شود . بنابراین طبق تعریف ، جداول مبنا دارای وجود و موجودیت مستقل بوده (independent existence) درحالی که جداول مشتق دارای این تعریف نیستند ( جداول مشتق متکی به جداول مبنا هستند ) .
بنابراین مشاهده می شود که یک جدول مشتق دقیقا جدولی است که برحسب جداول دیگری تعریف می شود و واضح است که یک جدول مبنا دقیقا یک جدول مشتق نمی باشد .
اکنون ، سیستم های رابطه ای به طور مشخص باید درمرحله اول امکانی را برای ایجاد جداول مبنا فراهم سازند، برای مثال در SQL این مورد توسط عبارت CREATE TABLE انجام می شود ( توجه کنید دراینجا منظور از TABLE دقیقا جدول مبنا می باشد ) و به طور مشخص جداول مبنا باید نامگذاری شوند ( درواقع نام آنها درعبارت و دستوری که آنها را ایجاد می کند ، قید خواهد شد .
برعکس ، اکثر جداول مشتق دارای نام نیستند ، بهرحال سیستم های رابطه ای معمولا نوع خاصی از جدول مشتق به نام دیدگاه (view) که دارای نام و اسم بوده را پشتیبانی می کنند . بنابراین یک دیدگاه (view) ، جدول دارای نامی است که برخلاف یک جدول مبنا ، بخودی خود دارای موجودیت مستقلی نمی باشد ، بلکه در عوض برحسب یک یا چند جدول دارای نام مربوطه ( جداول مبنا یا سایر دیدگاه ها ) تعریف شده است .
چنانچه عبارت تعریف دیدگاه بطور واقعی ارزیابی شود ، جدول مربوطه منتج خواهد شد ولی در واقع ، منظورابدا به این صورت نیست که آن جداول به یک نسخه مجزا(separate copy) اشاره می کند .یعنی هدف ما این نیست که پیشنهاد کنیم که واقعا عبارت تعریف دیدگاه ارزیابی می شود .
درحقیقت ، دیدگاه بطور موثری تنها یک پنجره (window) بر روی جدول EMP مربوط می باشد . البته ، مسلما هر تغییری بر روی جدول مربوطه به طور خودکار خیلی فوری از طریق پنجره قابل رویت خواهد بود ( البته این تغییرات درقسمت بدون سایه جدول EMP قرار میگیرد) . به طور مشابهی ، تغییرات بر روی TOPEMPS البته به طور خودکار و بلافاصله بر جدول واقعی EMP اعمال می گردد .و لذا قابل رویت از طریق پنجره خواهد بود .
یک نکته نهایی وجود دارد که نیاز است درخصوص موضوع جداول مبنا و دیدگاه مطرح گردد . تفاوت جدول مبنا و دیدگاه غالبا به صورت زیر تعریف می گردد .
جداول مبنا واقعا وجود دارند بدین مفهوم که آنها داده هایی را نشان می دهند که به طور واقعی در بانک اطلاعاتی ذخیره می شوند .
برعکس دیدگاه ها واقعا وجود ندارند اما آنها صرفا روشهای مختلف نگاه نمودن به داده های واقعی را فراهم می کنند .
هرچند این توصیف در یک حالت غیر رسمی یک بحث مفید است ولی دقیقا وضعیت درست مطالب را منعکس نمی کند . این مسئله درست است که کاربران می توانند جداول مبنا را همانگونه که آنها به طور فیزیکی وجود دارند ، درنظر بگیرند .
درواقع نکته اصلی و مهم شیوه رابطه ای این است که به کاربران این اجازه را می دهد تا آنها جداول مبنا را به عنوان یک موجودیت فیزیکی درنظر بگیرند. درحالی که مجبور نیستند به این مسئله توجه و دقت کنند که چگونه این جداول به طور فیزیکی درحافظه ذخیره می شوند .
ولی این مطلب یک اشکال بزرگ دارد بدین مفهوم که این روش تفکر نباید به عنوان مفهومی که یک جدول مبنا یک جدول ذخیره شده فیزیکی است ، درنظر گرفته شود ( یعنی ، مجموعه ای از رکوردهای همجوار فیزیکی و فیزیکی ذخیره شده که هرکدام شامل یک کپی مستقیم از یک جدول مبنا هستند ) جداول مبنا بهترین ایده و اندیشه به عنوان مجردسازی (abstraction) مجموعه ای از داده های ذخیره شده می باشند ( مجردسازی که در آن تمام جزئیات سطح – حافظه پنهان می باشد ) درعمل ، درجه دلخواهی از اختلاف بین یک جدول مبنا و جدول ذخیره شده وجود دارد .
1. معماری سه سطحی
از آنجا که درچگونگی معماری پایگاه داده ها حداقل درسالهای آغازین ایجاد این تکنولوژی ، بین کارشناسان ( از محافل مختلف علمی و تکنیکی ) اتفاق نظر نبود ، لذا ANSI/SPARC با توجه به اهمیت محیط انتزاعی ، معماری پایگاه داده ها را ( به عنوان یک معماری استانده (استاندارد)) ، پیشنهاد کرد ، این معماری به معماری سه سطحی موسوم است .
نکته 1: باید توجه داشت که این سه سطح اساسا سه سطح تعریف داده ها هستند : دوسطح درمحیط انتزاعی و سطح سوم در محیط فایلینگ منطقی . داده های ذخیره شده ( درمحیط فیزیکی ) طبعا درفایلهای فیزیکی جای دارند و هم از اینروست که پیشتر گفتیم : ساده ترین و کلی ترین تعریف پایگاه داده ها این است که گفته شود : مجموعه ای است از فایلهای .... .
حال نمای کاملتر معماری پیشنهادی ANSI رانشان داده ، به شرح هریک از سطوح معماری می پردازیم .
دراین معماری علاوه بر سه سطح ، اجزای دیگر هم دیده می شود که درواقع جزسیستم پایگاه داده ها هستند . دراینجا سه سطح و نیز اجزا دیگر را نام می بریم :