дсумку користувачеві доводиться комбінувати програмні продукти для отримання необхідного результату. У цьому сенсі все істотно спростять можливості, що надаються Microsoft Access.
СУБД Access призначена для розробки баз даних реляційного типу для локального їх використання на персональних комп'ютерах і для роботи з цими базами.
3.1 Збір інформації про предметну область
З точки зору проектування БД в рамках системного аналізу, необхідно здійснити перший етап, тобто провести докладний словесний опис об'єктів предметної області та реальних зв'язків, які присутні між описуваними об'єктами. Бажано, щоб даний опис дозволяло коректно визначити всі взаємозв'язки між об'єктами предметної області.
У загальному випадку існують два походи до вибору складу і структури предметної області:
· Функціональний підхід - він реалізує принцип руху «від завдань» і застосовується тоді, коли заздалегідь відомі функції деякої групи осіб і комплексів задач, для обслуговування інформаційних потреб яких створюється розглянута СУБД. У цьому випадку ми можемо чітко виділити необхідний мінімальний набір об'єктів предметної області, які повинні бути описані.
· Предметний підхід - коли інформаційні потреби майбутніх користувачів БД жорстко не фіксуються. Вони можуть бути багатоаспектними і вельми динамічними. Ми не можемо точно виділити мінімальний набір об'єктів предметної області, які необхідно описувати. В опис предметної області в цьому випадку включаються такі об'єкти і взаємозв'язки, які найбільш характерні і найбільш істотні для неї. БД, конструируемая при цьому, називається предметної, тобто вона може бути використана при вирішенні безлічі різноманітних, заздалегідь не визначених завдань.
Конструювання предметної БД в деякому розумінні здається набагато більш привабливим, однак труднощі загального охоплення предметної області з неможливістю конкретизації потреб користувачів може призвести до надлишково складною схемою БД, яка для конкретних завдань будет неефективною.
Найчастіше на практиці рекомендується використовувати певний компромісний варіант, який, з одного боку, орієнтований на конкретні завдання або функціональні потреби користувачів, а з іншого боку, враховує можливість нарощування нових додатків.
Дана база призначена для ведення обліку збірки оргтехніки, в ній знаходяться 4 таблиці, в які входять: «Службовці», «Товар», «Постачальник», «Рух товару». У таблицю «Службовці» входять такі атрибути як: код службовця, ПІБ, адреса, посада, заробітна плата, освіта, телефон. У таблицю «Товар» входять: код товару, вид, ціна, кількість. У таблицю «Постачальник» входять: код постачальника, ПІБ, адреса, телефон, код товару. У таблицю «Рух товару» входять: код товару, код службовця, код руху товару, вид руху товару, оптова ціна закупівлі, роздрібна ціна продажу, код постачальника.
3.2 Побудова інформаційно-логічної моделі даних
Инфологическая модель застосовується на другому етапі проектування БД, тобто після словесного опису предметної області. Процес проектування тривалий, він вимагає обговорень із замовником, з фахівцями в предметної області. Инфологическая модель повинна включати таке формалізований опис предметної області, яке легко буде" читатися» не тільки фахівцями по базах даних. І це опис має бути настільки ємним, щоб можна було оцінити глибину і коректність опрацювання проекту БД, і звичайно, як говорилося раніше, воно не повинно бути прив'язане до конкретної СУБД.
Інфологіческое проектування, насамперед, пов'язано зі спробою уявлення семантики предметної області в моделі БД. Реляційна модель даних в силу своєї простоти і лаконічності не дозволяє відобразити сенс предметної області.
Розглянемо проектування БД на прикладі предметної області «Оргтехніка».
Нехай необхідно побудувати базу даних, що містить інформацію про систему обліку складання виробів:
· перелік постачальників;
· список службовців;
· відомості про рух товарів.
На підставі аналізу предметної області ми виділили такі сутності моделі «сутність-зв'язок» («Entity Relationship» - ER-моделі): «Постачальники», «Службовці», «Товар», «Рух товару».
На підставі уважного аналізу предметної області можна виділити наступні сутності моделі сутність-зв'язок: «Рух товару», «Постачальник», «Службовці», «Товар», «Поставка фірмі», «Постачальник», « Служба доставки »,« Рахунок »,« Товари »(малюнок 2).
Рух товару Код товару Код службовця Код руху товару Код постачальника Вид руху товару Оптова ціна заку...
