омії пам'яті, скільки для виключення можливої ??суперечливості збережених даних.
Найбільш поширеними методами проектування БД зараз є метод ER-діаграм і метод функціональних залежностей.
Для проектування бази даних скористаємося методом ER-діаграм. Суть цього методу полягає у встановленні сутностей і зв'язків між ними.
ER-діаграми зручні тим, що процес виділення сутностей, атрибутів і зв'язків є ітераційним. Після того, як буде розроблений перший наближений варіант діаграми, його уточнюють, опитуючи експертів предметної області. При цьому документацією, в якій фіксуються результати бесід, є самі ER-діаграми.
Розрізняють концептуальні і фізичні ER-діаграми. Концептуальні діаграми не враховують особливостей конкретних СУБД. Фізичні діаграми будуються по концептуальних диаграммам і являють собою прообраз конкретної бази даних. Сутності, певні в концептуальній діаграмі стають таблицями, атрибути стають колонками таблиць (при цьому враховуються допустимі для даної СУБД типи даних і найменування стовпців), зв'язки реалізуються шляхом міграції ключових атрибутів батьківських сутностей і створення зовнішніх ключів [13].
При правильному визначенні сутностей, отримані таблиці будуть відразу перебувати в 3НФ. Основна перевага методу полягає в тому, модель будується методом послідовних уточнень первинних діаграм.
.2 Розробка концептуальної моделі бази даних
На етапі концептуального проектування найбільш часто використовується спадна методологія проектування концептуальної схеми - схема «від загального до конкретного». Її суть полягає в переході від якоїсь абстрактної сутності, що володіє всіма можливими властивостями, згідно опису зовнішнього подання, з поступовим уточненням вимог, до формування нових сутностей, з новими зв'язками і визначенням належності властивостей тієї чи іншої суті або зв'язку. Так як програмний продукт є початковим етапом створення автоматизованої системи ідентифікації та простежуваності в організації, то не обходимо при розробці структури бази даних, враховувати можливість подальшого розширення та кількості зберігаються параметрів.
Виходячи з останніх вимог, варто припустити, що необхідно, по можливості, винести параметри базових сутностей в окремі таблиці. Що дозволить без змін структури бази даних розширити спектр збережених параметрів.
Прикладом такого підходу можна назвати структуру таблиць для зберігання машин клієнтів і відомостей про них показаної на малюнку 3.1
Малюнок 3.1 - Структуру таблиць для зберігання машин клієнтів
В основній таблиці «car» зберігатися тільки основні параметри автомобіля:
Таблиця 3.1 - Типи полів у таблиці «car»
Ім'я поляТіп поляОписаниеcar_idСчетчикУникальный кодbrand_idЧісловойСсилка на таблицю цінових группclient_idЧісловойСсилка на таблицю клиентовnumberТекстовыйГосударственный номер автотранспортного средстваmodelТекстовыймодель машини
Для зберігання інших параметрів використовується таблиці «car_param» і «car_param_text». У таблиці «car_param_Text» зберігаються назви параметрів, так як вони будуть часто повторюватися. Таблиця «car_param_Text» містить записи описують параметри. Од...
