close

Вход

Забыли?

вход по аккаунту

?

кр

код для вставкиСкачать
 Міністерство освіти і науки України
Сумський державний університет
Кафедра комп'ютерних наук
Секція інформаційних технологій проектування
Пояснювальна записка до
курсової роботи
з дисципліни
"Організація баз даних і знань"
на тему
"Розроблення бази даних для агентства нерухомості"
ВикладачМарченко А. В.
СтудентЧерняков С. М.
ГрупаІТ-21
Варіант25
Суми - 2013
Сумський державний університет
Факультет ___ЕлІТ __Кафедра комп'ютерних наук
Секція інформаційних технологій проектування
Напрям підготовки - 6.050101 Комп'ютерні науки
Спеціальність Інформаційні технології проектування
ЗАВДАННЯ
на комплексний курсовий проект
Чернякову Сергію Михайловичу
(прізвище, ім'я, по батькові)
1 Тема роботи Розроблення бази даних для підтримки діяльності агентства нерухомості.
2 Термін здачі студентом закінченої роботи "07" грудня 2013 р.
3 Вхідні дані до роботи Каталог приміщень: код, тип (житлові/нежитлові), призначення (для оренди та/або продажу), відомості про покупців: анкетні дані, банківські дані, відомості про продавців: анкетні дані, банківські дані, журнал угод: номер реєстрації, продавець, покупець, тип угоди, вартість угоди, приміщення, термін оренди, умови оренди.
4 Зміст розрахунково-пояснювальної записки (перелік питань, які необхідно вирішити) Аналіз предметної області, моделювання бази даних, реалізація моделі бази даних в СУБД, тестування бази даних.
5 Перелік графічного матеріалу (з точним зазначенням обов'язкових креслень) Графічні матеріали відсутні
КАЛЕНДАРНИЙ ПЛАН
№ п/пНазва етапів роботиТермін виконання етапів роботиПримітка1Отримання завдання. Аналіз ПО та визначення задач створення БД та вимог до неї25-26.09.20132Розроблення концептуальної моделі БД 01-04.10.20133Розроблення логічної моделі БД21-25.10.20134Вибір СУБД. Розроблення фізичної моделі БД04-08.11.20135Реалізація моделі БД в СУБД18-22.11.20136Тестування БД25-30.11.20137Оформлення ПЗ02-07.12.20138Захист КР09-14.12.2013 СтудентЧерняков С. М. (підпис)
Керівник роботиМарченко А.В. (підпис)(прізвище та ініціали)
РЕФЕРАТ Тема роботи "Розроблення бази даних для агентства нерухомості".
Пояснювальна записка 33 с., 3 додатків, 9 літературних джерел.
Під час роботі над курсовою роботою були закріплені навички розроблення концептуальної, логічної та фізичної моделей даних, та роботи в СУБД MySQL.
Робота присвячена розробленню бази даних для підтримки діяльності агентства нерухомості. Результати роботи подані у вигляді схем концептуальної, логічної та фізичної моделей даних. Для розроблення моделей використані засоби ER-методології моделювання.
Тестування реалізованої бази даних підтверджує адекватність розробленої моделі.
Ключові слова: ER-методологія, модель даних, база даних, MySQL.
ЗМІСТ
Вступ5
Аналіз предметної області8
Вхідні дані8
Вихідні дані8
Функціонал8
Визначення сутностей та атрибутів8
Визначення зв'язків9
Розроблення бази даних10
Концептуальне моделювання10
Логічне моделювання12
Фізичне моделювання15
Облік транзакцій16
Реалізація бази даних21
Тестування24
Висновки26
Список використаної літератури27
Додаток А. Завдання курсової роботи28
Додаток Б. Створення бази даних29
Додаток в. Заповнення бази даних32
ВСТУП
База даних (БД) - це іменована сукупність даних, що відображає стан об'єктів та їх відносин у розглядуваній предметній області.
Під предметною областю прийнято розуміти деяку область людської діяльності або область реального світу, які підлягають вивченню для організації управління та автоматизації.
Система управління базами даних (СУБД) - це сукупність мовних та програмних засобів, призначених для створення, наповнення, оновлення та видалення баз даних.
Програми, за допомогою яких користувачі працюють з БД, називаються додатками.
До сучасних баз даних, а, отже, і до СУБД, на яких вони будуються, пред'являються наступні основні вимоги:
1. Висока швидкодія (малий час відгуку на запит). Час відгуку - проміжок часу від моменту запиту БД до фактичного отримання даних. 2. Простота оновлення даних.
3. Незалежність даних.
4. Спільне використання даних багатьма користувачами.
5. Безпека даних - захист даних від навмисного чи ненавмисного порушення секретності, спотворення або руйнування.
6. Стандартизація побудови та експлуатації БД (фактично СУБД).
7. Адекватність відображення даних відповідної предметної області.
8. Доброзичливий інтерфейс користувача.
Найважливішими є перші дві вимоги, оскільки підвищення швидкодії вимагає спрощення структури БД, що, у свою чергу, ускладнює процедуру оновлення даних, збільшує їх надмірність.
Незалежність даних - можливість зміни логічної та фізичної структури БД без зміни уявлень користувачів.
Незалежність даних передбачає інваріантність до характеру зберігання даних, програмного забезпечення і технічних засобів. Вона забезпечує мінімальні зміни структури БД при змінах стратегії доступу до даних і структури самих вихідних даних. Це досягається "зсувом" всіх змін на етапи концептуального і логічного проектування з мінімальними змінами на етапі фізичного проектування.
Безпека даних включає їх цілісність і захист.
Цілісність даних - стійкість даних, що зберігаються до руйнування і знищення, пов'язаних з несправностями технічних засобів, системними помилками і помилковими діями користувачів.
Безпека даних передбачає:
- відсутність неточно введених даних, або двох однакових записів про один й той же факт;
- захист від помилок при оновленні БД;
- неможливість видалення пов'язаних даних різних таблиць;
- збереження даних при збої техніки (відновлення даних).
Цілісність забезпечується тригерами цілісності - спеціальними програмами, що працюють за певних умов. Захист даних від несанкціонованого доступу припускає обмеження доступу до конфіденційних даних і може досягатися:
- введенням системи паролів;
- отриманням дозволів від адміністратора бази даних (АБД);
- забороною від АБД на доступ до даних;
- формування видів (таблиць, похідних від вихідних і призначених конкретним користувачам).
Три останні процедури легко виконуються в рамках структурованої мови запитів (Structured Query Language- SQL).
Стандартизація забезпечує спадкоємність поколінь СУБД, спрощує взаємодію БД одного покоління СУБД з однаковими і різними моделями даних. Стандартизація (ANSI/SPARC) здійснена в значній мірі в частині інтерфейсу користувача СУБД і мови SQL. Це дозволило успішно вирішити завдання взаємодії різних реляційних СУБД, як за допомогою мови SQL, так і з застосуванням програми OpenDataBaseConnection (ODBC). При цьому може бути здійснено як локальний, так і віддалений доступ до даних (технологія клієнт/сервер або мережевий варіант).
Метою даної курсової є розроблення БД для підтримки діяльності агентства нерухомості. Основною задачею є створення надійної бази даних, оскільки надійність є однією з головних вимог. Щоб перевірити надійність бази даних необхідно буде провести ретельне тестування.
Для того, щоб досягти поставленої мети необхідно проаналізувати предметну область, виділити потенційні сутності та атрибути, на їх основі побудувати концептуальну модель. Після чого провести глибокий аналіз концептуальної моделі та на її основі побудувати логічну модель, при цьому, за необхідності, провести декомпозицію сутностей та позбутися зайвих зв'язків. На основі логічної моделі необхідно розробити внутрішню схему бази даних та створити основні транзакції, після чого можна переходити до реалізації бази даних в СУБД та подальшого тестування.
АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ
Назва предметної області: Агентство нерухомості.
Ця предметна область складається із вхідних та вихідних даних. Основною задачею є розробка бази даних для підтримки діяльності агентства нерухомості.
Вхідні дані
Каталог приміщень: код, тип (житлові/нежитлові), призначення (для оренди та/або продажу). Відомості про покупців: анкетні дані, банківські дані.
Відомості про продавців: анкетні дані, банківські дані.
Журнал угод: номер реєстрації, продавець, покупець, тип угоди, вартість угоди, приміщення, термін оренди, умови оренди. Вихідні дані
* Інформація про продані і здані в оренду приміщення на певну дату.
* Наявність приміщень різних типів.
* Умови договору по клієнтах.
* Умови договору по приміщеннях.
Функціонал
* Пошук варіантів відповідно до вимог клієнта.
* Ведення каталогу приміщень.
* Формування заявок від продавців.
* Формування договору угод.
Визначення сутностей та атрибутів
Аналізуючи вхідні дані виокремлюємо іменники, які можуть бути сутностями:
* приміщення;
* продавець;
* покупець;
* угода.
Визначаємо атрибути сутностей:
* Приміщення: код, адреса, тип (житлові/нежитлові), площа.
* Покупець: номер паспорту, ім'я, прізвище, банківські дані.
* Продавець: номер паспорту, ім'я, прізвище, банківські дані.
* Угода: номер реєстрації, продавець, покупець, тип угоди, вартість угоди, приміщення, термін оренди, умови оренди.
Визначення зв'язків
Продавець заключає угоду.
Угода містить дані продавця.
Покупець заключає угоду.
Угода містить дані покупця.
Приміщення є предметом угоди.
Угода містить дані про приміщення.
РОЗРОБЛЕННЯ БАЗИ ДАНИХ
Концептуальне моделювання
Після аналізу предметної області перейдемо до побудови концептуальної моделі бази даних. Спочатку потрібно розробити концептуальну модель сутностей (рис. 1), а вже потім додати до цієї моделі атрибути та, за необхідності, позбавитися зайвих зв'язків.
У концептуальній моделі сутностями виступають продавець(seller), покупець(buyer), приміщення(building), угода(contract). Зв'язки seller-> contract, buyer-> contract та building->contract мають потужність однина до множини, так як продавці і покупці можуть мати декілька контрактів, а також на одне приміщення можуть бути оформлені декілька угод. Факультативним є лише зв'язок building->contract, оскільки приміщення не обов'язково повинно здаватися оренду або продаватися.
Концептуальна модель наочно показує, які атрибути належать до певних сутностей. Було виділено основні ключові поля та зовнішні ключі. Дана модель потребує глибокого аналізу та в подальшому буде використовуватися для створення логічної моделі.
Логічне моделювання
Створивши концептуальну модель необхідно її проаналізувати, та на її основі створити логічну модель. Проаналізувавши сутність contract, її було декомпозовано на дві сутності: заява(declaration) та угода(contract).
Продавець залишає агентству нерухомості заявку(declaration), яка містить ідентифікатор продавця, ідентифікатор будівлі, тип угоди(оренда або продаж) та плату(щомісячну або одноразову). Агентство знаходить покупця(buyer), з яким підписується угода(contract). Угода(contract) містить дані заявки від продавця, ідентифікатор покупця, дату придбання приміщення або дати початку і кінця оренди.
Проаналізуємо сутність приміщення(building). Сутність має складений атрибут: адреса(address). Декомпозуємо її:
Приміщення(building) має свою адресу(address_id), тип(type), який визначає житлове чи нежтлове приміщення та площу(square). Адреса(address) включає в себе країну(country), місто(sity), вулицю(street) та номер будинку(house).
Аналізуючи базу даних доходимо до висновку, що вона нормалізована.
На етапі логічного моделювання було декомпозовано дві сутності і тому в кінцевому результаті ми отримали шість сутностей. Три з них є базовими, а три підлеглими, що буде дуже важливим на етапі фізичного моделювання, оскільки внутрішня схема бази даних розробляється на основі логічної моделі.
Фізичне моделювання
На основі логічної моделі можна створити фізичну модель БД. Спочатку необхідно виділити, які таблиці є базовими, а які підлеглими. Базовими є таблиці seller, buyer та address а підлеглими building, declaration, contract.
Розроблення внутрішньої схеми БД ділиться на шість етапів:
* Першим етапом створення фізичної моделі є створення базових таблиць і тільки після їх створення можна перейти до створення підлеглих, оскільки підлеглі таблиці використовують зовнішні ключі, які будуть посилатися на первинні ключі базових таблиць. Використовується синтаксис з використанням оператора групи DLL. Текст для створення таблиць наведено у додатку Б.
* Другим етапом стало додавання колонок до базових таблиць. Колонки представляють собою атрибути відношень логічної моделі реляційної БД. * Третім етапом є визначення типів даних для колонок відповідно дозволеним для даної СУБД типам даних.
* Четвертим етапом було визначено первинні ключові поля таблиць (PRIMARY KEY).
* Після визначення первинних ключових полів таблиць, переходимо до п'ятого етапу - створення унікального індексу первинного ключа, за допомогою команди "CREATE UNIQUE INDEX".
* Шостим етапом необхідно визначити обмеження NOT NULL на обов'язковість присутності значення колонок та об'явити зовнішні ключові поля. Колонки, що є частиною первинного ключа повинні завжди мати обмеження NOT NULL. Таке ж обмеження повинне бути визначене для зовнішніх ключових полів.
Облік транзакцій
Після розроблення внутрішньої схеми бази даних необхідно перейти до опрацювання можливих транзакцій.
Необхідне виконання наступних транзакцій:
* Інформація про продані і здані в оренду приміщення на певну дату.
* Наявність приміщень різних типів.
* Умови договору по клієнтах.
* Умови договору по приміщеннях.
Ім'я транзакції: Інформація про продані і здані в оренду приміщення на певну дату.
Номер транзакції: 1.
Опис транзакції: транзакція виводить інформацію про будівлі, які куплені в цей день або перебувають в оренді.
Характер транзакції і її складність: он-лайнова; середня складність. Обсяг транзакції: середня частота - до 10 в день; пікова частота - 5 в годину. Вимоги до продуктивності транзакції - час реакції не більше 4 секунд. Відносний пріоритет: 5
КомандаКоментарSELECT
address.country AS 'Країна',
address.city AS 'Місто',
address.street AS 'Вулиця',
address.house AS 'Будинок',
building.type AS 'Житлова будівля-1 Нежитлова-0',
declaration.type AS 'Продаж-1 Оренда-0',
building.square AS 'Площа',
contract.startdate AS 'Дата початку оренди',
contract.enddate AS 'Дата кінця оренди'
FROM contract, declaration, building, address
WHERE contract.declaration_id=declaration.declaration_id
AND declaration.building_id=building.building_id
AND building.address_id=address.address_id
AND ((contract.startdate<=20131218 AND contract.enddate>=20131218)
OR (contract.startdate=20131218 AND declaration.type=1))Виводить інформацію про будівлі, які куплені в цей день або перебувають в оренді.
Кількість рядків, що можуть бути задіяні в транзакції, дорівнює поточному розміру таблиць contract, declaration, building, address
Ім'я транзакції: Наявність приміщень різних типів.
Номер транзакції: 2.
Опис транзакції: транзакція виводить інформацію про будівлі,на які існують заявки проте вони не є предметом жодної угоди.
Характер транзакції і її складність: он-лайнова; середня складність. Обсяг транзакції: середня частота - до 10 в день; пікова частота - 5 в годину. Вимоги до продуктивності транзакції - час реакції не більше 4 секунд. Відносний пріоритет: 5
КомандаКоментарSELECT
address.country AS 'Країна',
address.city AS 'Місто',
address.street AS 'Вулиця',
address.house AS 'Будинок',
building.type AS 'Житлова будівля-1 Нежитлова-0',
building.square AS 'Площа',
declaration.type AS 'Продаж-1 Оренда-0',
declaration.payment AS 'Ціна'
FROM declaration, building, address
WHERE
building.address_id=address.address_id
AND declaration.building_id=building.building_id
AND declaration.declaration_id NOT IN
(
SELECT declaration_id
FROM contract
)Виводить інформацію про будівлі,на які існують заявки проте вони не є предметом жодної угоди.
Кількість рядків, що можуть бути задіяні в транзакції, дорівнює поточному розміру таблиць declaration, building, address
Ім'я транзакції: Умови договору по клієнтах.
Номер транзакції: 3.
Опис транзакції: транзакція виконує пошук за клієнтом та виводить інформацію про угоду.
Характер транзакції і її складність: он-лайнова; середня складність. Обсяг транзакції: середня частота - до 10 в день; пікова частота - 5 в годину. Вимоги до продуктивності транзакції - час реакції не більше 4 секунд. Відносний пріоритет: 5
КомандаКоментарSELECT
seller.name AS 'Ім"я продавця',
seller.surname AS 'Прізвище продавця',
buyer.name AS 'Ім"я покупця',
buyer.surname AS 'Прізвище покупця',
address.country AS 'Країна', address.city AS 'Місто',
address.street AS 'Вулиця', address.house AS 'Будинок',
building.type AS 'Житлова будівля-1 Нежитлова-0',
building.square AS 'Площа',
declaration.type AS 'Продаж-1 Оренда-0',
declaration.payment AS 'Ціна'
FROM declaration, building, address, seller, buyer, contract
WHERE
contract.declaration_id=declaration.declaration_id
AND declaration.building_id=building.building_id
AND building.address_id=address.address_id
AND contract.bpassport_id=buyer.bpassport_id
AND declaration.spassport_id=seller.spassport_id
AND (seller.surname='Гагарін' OR buyer.surname='Гагарін')Транзакція виконує пошук за клієнтом та виводить інформацію про угоду.
Кількість рядків, що можуть бути задіяні в транзакції, дорівнює поточному розміру таблиць declaration, building, address, seller, buyer, contract Ім'я транзакції: Умови договору по приміщеннях.
Номер транзакції: 4.
Опис транзакції: транзакція виконує пошук за приміщенням та виводить інформацію про угоду.
Характер транзакції і її складність: он-лайнова; середня складність. Обсяг транзакції: середня частота - до 10 в день; пікова частота - 5 в годину. Вимоги до продуктивності транзакції - час реакції не більше 4 секунд. Відносний пріоритет: 5
КомандаКоментарSELECT
seller.name AS 'Ім"я продавця',
seller.surname AS 'Прізвище продавця',
buyer.name AS 'Ім"я покупця',
buyer.surname AS 'Прізвище покупця',
address.country AS 'Країна', address.city AS 'Місто',
address.street AS 'Вулиця', address.house AS 'Будинок',
building.type AS 'Житлова будівля-1 Нежитлова-0',
building.square AS 'Площа',
declaration.type AS 'Продаж-1 Оренда-0',
declaration.payment AS 'Ціна'
FROM declaration, building, address, seller, buyer, contract
WHERE
contract.declaration_id=declaration.declaration_id
AND declaration.building_id=building.building_id
AND building.address_id=address.address_id
AND contract.bpassport_id=buyer.bpassport_id
AND declaration.spassport_id=seller.spassport_id
AND address.street='М. Лушпи'Транзакція виконує пошук за приміщенням та виводить інформацію про угоду.
Кількість рядків, що можуть бути задіяні в транзакції, дорівнює поточному розміру таблиць declaration, building, address, seller, buyer, contract РЕАЛІЗАЦІЯ БАЗИ ДАНИХ
Після розроблення фізичної моделі перейдемо до реалізації СУБД MySQL.
Спочатку створюємо нову базу даних.
Рисунок 3.1 - створення нової БД.
Додаємо базові таблиці та їх індекси.
Рисунок 3.2 - створення базової таблиці.
Додаємо єднальні таблиці, зовнішні ключі та індекси таблиць.
Рисунок 3.3 - створення єднальної таблиці.
Після створення бази даних перевіряємо її у вбудованому дизайнері.
Рисунок 3.4 - перегляд БД у дизайнері.
Після створення та перевірки бази даних заповнюємо її.
Рисунок 3.4 - заповнення БД.
ТЕСТУВАННЯ
Останнім етапом у розробленні бази даних є етап тестування. Для того, щоб провести тестування використовуються розроблені раніше транзакції.
Перша транзакція виводить інформацію про будівлі, які куплені в цей день або перебувають в оренді
Друга транзакція виводить інформацію про будівлі,на які існують заявки проте вони не є предметом жодної угоди.
Третя транзакція виконує пошук за клієнтом та виводить інформацію про угоду.
Четверта транзакція виконує пошук за приміщенням та виводить інформацію про угоду.
На фазі тестування в БД не було помічено значних недоліків, запити оброблялися достатньо швидко, навіть на не дуже потужних комп'ютерах. Це говорить про те, що було обрано правильну кількість таблиць і запити при роботі з декількома таблицями не мають впливу на швидкодію.
ВИСНОВКИ
В ході виконання курсової роботи я провів дослідження і проектування БД "Агентство нерухомості". Розроблена база даних призначена для зберігання інформації необхідної для функціонування агентства. Цю роботу умовно можна розділити на декілька етапів:
* аналіз предметної області;
* концептуальне моделювання;
* логічне моделювання;
* фізичне моделюваня;
* реалізація моделі даних в СУБД та тестування бази даних.
Розглянемо більш детально етапи розробки БД.
В результаті виконання першого етапу були виділені сутності та атрибути, встановлені початкові зв'язки між сутностями.
Результатом виконання наступного етапу стала концептуальну модель сутностей та атрибутів, проаналізувавши цю модель ми перейшли до наступного етапу - логічне моделювання. Декомпозувавши дві сутності, ми в результаті замість трьох сутностей отримали шість. В результаті виконання четвертого етапу було розроблено внутрішню схему бази даних та транзакції. Цей етап необхідний для реалізації моделі даних в СУБД. Останнім етапом було тестування бази даних в СУБД. Для цього ми обрали СУБД MySQL. Було створено сім таблиць та заповнено кожну п'ятьма параметрами. Під час реалізації запитів не було помічено значних недоліків, це означає, що фізична модель була реалізована вірно.
В ході виконання роботи були удосконалені та закріплені знання та вміння по роботі з базами даних.
СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ
1. Дейт, К. Д. Введение в системы баз данных / К. Д. Дейт; Пер. с англ. и ред. К. А. Птицына - М. и др. : Вильямс, 2006 - 1328 с. 2. Карпова, Т. С. Базы данных: Модели, разработка, реализация : Учеб. пособие / Т. С. Карпова - СПб. и др. : Питер , 2002. - 304 с. 3. Кетов А. В. Информационные системы : учеб. пособие / А. В. Кетов. - Хабаровск : Изд-во Хабар. гос. техн. ун-та, 2002. - 59 с. 4. Малыхина М. П. Базы данных: основы, проектирование, использование : учеб. пособие / М. П. Малыхина. - СПб. : БХВ-Петербург, 2004. - 512 с 5. Голицына О. Л. Базы данных : учеб. пособие / О. Л. Голицына, Н. В. Максимов, И. И. Попов. - М. : ФОРУМ : ИНФРА-М, 2004.- 352 с.. 6. Коннолли Т. Базы данных: проектирование, реализация и сопровождение. Теория и практика : пер. с англ. / Т. Коннолли, К. Бегг, А. Страчан. - М. : Издательский дом "Вильямс", 2000. - 1120 с 7. Пасічник В.В.Організація баз даних та знань: підручник для ВНЗ/ В.В. Пасічник, В.А. Резніченко.- К.: Видавнича група BHV,2006.-384с. 8. В.Е. Туманов. Основы проектирования реляционных баз данных - http://www.intuit.ru. 9. Пушников А.Ю. Введение в системы управления базами данных. Часть 2. Нормальные формы отношений и транзакции: Учебное пособие/Изд-е Башкирского ун-та. - Уфа, 1999. - 138 с.
ДОДАТОК А. ЗАВДАННЯ КУРСОВОЇ РОБОТИ
ДОДАТОК Б. СТВОРЕННЯ БАЗИ ДАНИХ
CREATE TABLE seller
(
spassport_id char(8) NOT NULL,
name char(20),
surname char(20),
account char(20),
PRIMARY KEY (spassport_id)
);
CREATE UNIQUE INDEX NDXSELLER ON seller(spassport_id);
CREATE TABLE buyer
(
bpassport_id char(8) NOT NULL,
name char(20),
surname char(20),
account char(20),
PRIMARY KEY (bpassport_id)
);
CREATE UNIQUE INDEX NDXBUYER ON buyer(bpassport_id);
CREATE TABLE address
(
address_id integer NOT NULL,
country char(20),
city char(20),
street char(20),
house char(10),
PRIMARY KEY (address_id)
);
CREATE UNIQUE INDEX NDXADDRESS ON address(address_id);
CREATE TABLE building
(
building_id integer NOT NULL,
address_id integer,
type boolean,
square dec(6,2),
PRIMARY KEY (building_id),
FOREIGN KEY (address_id) REFERENCES address(address_id)
);
CREATE UNIQUE INDEX NDXBUILDING ON building(building_id);
CREATE TABLE declaration
(
declaration_id integer NOT NULL,
spassport_id char(8),
building_id integer,
type boolean,
payment dec(10,2),
PRIMARY KEY (declaration_id),
FOREIGN KEY (spassport_id) REFERENCES seller(spassport_id),
FOREIGN KEY (building_id) REFERENCES building(building_id)
);
CREATE UNIQUE INDEX NDXDECLARATION ON declaration(declaration_id);
CREATE TABLE contract
(
contract_id integer NOT NULL,
declaration_id integer,
bpassport_id char(8),
startdate date,
enddate date,
PRIMARY KEY (contract_id),
FOREIGN KEY (declaration_id) REFERENCES declaration(declaration_id),
FOREIGN KEY (bpassport_id) REFERENCES buyer(bpassport_id)
);
CREATE UNIQUE INDEX NDXCONTRACT ON contract(contract_id);
ДОДАТОК В. ЗАПОВНЕННЯ БАЗИ ДАНИХ
INSERT INTO seller(spassport_id, name, surname, account) VALUES
('ВО183289','Антон','Терещенко','16432578426548512549'),
('ЕК218325','Олександр','Карпов','45121578639955218622'),
('ТВ482162','Юрій','Антонов','72518231981642354862'),
('МВ874534','Євгеній','Гагарін','79678913184613865548'),
('ЕИ459821','Максим','Пахов','24761865598562618246');
INSERT INTO buyer(bpassport_id, name, surname, account) VALUES
('ЕТ674676','Віталій','Азаров','76221522139883295315'),
('ТВ987687','Олексій','Сорока','14589601561035154014'),
('РВ123423','Андрій','Каріка','17589160527458474350'),
('КП235235','Ігор','Осадчий','46132461348947934865'),
('УН458128','Анатолій','Міненко','75115676317431475676');
INSERT INTO address(address_id, country, city, street, house) VALUES
(4001,'Україна','Київ','Хрещатик','48'),
(4002,'Україна','Київ','Б. Хмельницького','12'),
(4003,'Україна','Київ','Гната Юри','58/13'),
(4004,'Україна','Суми','М. Лушпи','28/56'),
(4005,'Україна','Полтава','пл. Миру','47'),
(4006,'Україна','Одеса','Г. Матросова','2'),
(4007,'Україна','Ужгород','Л. Українки','96');
INSERT INTO building(building_id, address_id, type, square) VALUES
(3001,4001,0,25.2),
(3002,4002,0,245.6),
(3003,4003,1,23.6),
(3004,4004,1,47.2),
(3005,4005,0,238.5),
(3006,4006,1,23.6),
(3007,4007,1,47.2);
INSERT INTO declaration(declaration_id, spassport_id, building_id, type, payment) VALUES
(1001,'ВО183289',3001,0,5600),
(1002,'ЕК218325',3002,0,35000),
(1003,'ТВ482162',3003,0,7400),
(1004,'МВ874534',3004,1,95000),
(1005,'ЕИ459821',3005,1,247000),
(1006,'ТВ482162',3006,0,1500),
(1007,'ВО183289',3007,1,95000);
INSERT INTO contract(contract_id, declaration_id, bpassport_id, startdate, enddate) VALUES
(2001,1001,'ЕТ674676',20120512,20130512),
(2002,1002,'ТВ987687',20130101,20131231),
(2003,1003,'РВ123423',20130201,20131201),
(2004,1004,'КП235235',20140101,NULL),
(2005,1005,'УН458128',20131218,NULL);
33
Документ
Категория
Рефераты
Просмотров
112
Размер файла
1 203 Кб
Теги
1/--страниц
Пожаловаться на содержимое документа