Големина на текста:
Разработване на логически модел на данните
Когато се проектира една база данни, е необходимо да се вземат решения по
отношение на създаването на най-удобния модел на дадена система от реалния свят.
При създаване на модела на данните се извършва организиране на изискванията на
системата в едно логическо представяне на базата данни. Моделът на данните се състои
от обекти и техните атрибути и ограничения, дефиниции на релации между обектите и
ограничения върху тези релации, следователно разработването на логически модел на
данните се осъществява чрез определяне на обектите, техните атрибути и ограничения
и техните релации. Създаденият по този начин модел позволява да се идентифицират
съответните таблици, които трябва да бъдат създадени, колоните, съдържащи се в тях,
релациите между таблиците.
?Определяне на обектите и техните атрибути;
Когато се определят обектите, е необходимо, от изискванията на системата да се
дефинират основните логически подразделения на информацията. Например да
предположим, че се проектира база данни за една система за заемане на видеокасети.
Докато се разглеждат изискванията на системата, се дефинират следните основни
обекти и събития – видеокасети, клиенти, заемания. В резултат на това се добавят
таблици към дизайна на базата данни, които им съответстват – Videocassettes,
Customers, Rents. При определянето на работните правила за тази система се
установява, че във видеотеката има определен брой n категории филми и че редовните
клиенти имат предпочитания към определена категория филми. Вследствие на това се
създава таблица за категориите видеокасети Categories и се уточнява наличието на
атрибут “категория на филм” в таблицата Videocassettes и таблицата Customers,
от които ще има препратки към таблицата Categories, без да е необходимо да се
повтаря описанието на типа на филма за всяка видеокасета и всеки клиент.
След като са дефинирани всички таблици, които могат да бъдат определени в
този момент, трябва да се дефинират колоните (атрибутите) на тези таблици. Тази
информация се взема директно от изискванията на системата, в които е определено
какви данни трябва да се поддържат за обектите и събитията. От примера за база данни,
която да обработва информацията, необходима на една видеотека, ако се разгледа
таблицата Customers, може да се предположи, че по време на определяне на
изискванията на системата е зададено, че трябва да съдържа информация за имената и
фамилиите на клиентите, адресите, телефонните номера, предпочитаните филми.
Вследствие на това се добавят колони към таблицата Customers за всеки от тези
видове информация. Освен това се добавя уникален идентификатор на всеки клиент,
както се прави при всички нормализирани обекти. Колоните, които съдържа таблицата
Customers, са показани на фиг. 1.
Customers
CustomerID
FirstName
Surname
LastName
Address
City
PostalCode
PhoneNumber
CategoryID
Фиг. 1 Таблицата, съдържаща данните за клиентите
1
?Определяне на релациите между обектите;
По време на процеса на дефиниране на релациите между таблиците може да се
открие, че е необходимо да се промени създадения до този момент дизайн. Започва се с
избиране на една от основните таблици и определяне на обектите, които имат релации
към тази таблица. Разглеждайки базата данни, използвана в предишните примери, може
да се приеме, че в изискванията на системата е заложено във всяко заемане да има
информация за видеокасетите и клиентите. Следователно съществува релация между
видеокасетите и заеманията и между клиентите и заеманията. Аналогично се
установяват и останалите релации между таблиците Videocassettes и
Categories и между таблиците Customers и Categories (фиг. 2).
Фиг. 2 Релациите между таблиците в разглежданата база данни
След като се установят релациите между таблиците, трябва да се дефинира типа
на тези релации. Всяка линия се маркира в двата си края или с цифрата 1, или със
символа за безкрайност ?. Цифрата 1 се отнася до страната “едно” на релацията, а
символът ? се отнася до страната “много” на релацията. За да се определи типа на
релацията, се разглеждат данните, които съдържат таблиците и видовете
взаимоотношения между тях. Например според работните правила един клиент може
да направи едно или повече заемания, но във всеки запис за заемане трябва да има
точно един идентификатор на клиент, следователно между таблиците Customers и
Rents съществува релация “едно към много”. Освен това според работните правила
заемането може да се направи за една или повече видеокасети, а една видеокасета може
да бъде посочена в едно или повече заемания (на различни дати), следователно между
таблиците Videocassettes и Rents съществува релация “много към много”. В един
нормализиран проект на базата данни обаче релациите “много към много” трябва да се
модифицират, като се добави една свързваща таблица и между нея и всяка
първоначална таблица да се създадат релации “едно към много” (фиг. 3).
Фиг. 3 Представяне на релацията “много към много” чрез добавяне на
свързващата таблица CassetteRent
Аналогично се определят и типовете на останалите релации.
2
Categories
VideocassettesCustomers
Rents
11
1
?
?
??
?
Categories
VideocassettesCustomers
Rents
11
1
?
1
1
?
?
CassetteRent
?
?
?Определяне на ограниченията върху данните.
Работните правила включват всички ограничения за една система, включително
за целостта на данните и сигурността. На този етап от процеса на проектиране трябва
да се обърне внимание на специфичните за ограниченията върху данните. Например да
допуснем, че едно от правилата е формулирано по следния начин: “Записът за един
клиент на видеотеката може, но не е задължително да включва някое от предварително
дефинираните предпочитания за вида на филма, но не може да включва и друго
предпочитание.” Следователно колоната CategoryID в таблицата Customers не
изисква задължително попълнена стойност; всяка стойност с изключение на NULL,
въведена в нея трябва да съществува в колоната CategoryID в таблицата
Categories. С аналогични разсъждения се достига до извода, че в таблицата Rents
колоната CustomerID трябва задължително да има попълнена стойност и тя да
съществува като стойност в колоната CustomerID от таблицата Customers, т.н.
Задачи
Задача 1. Да се разработи логическия модел на данните, необходим за
проектиране и изграждане на една база данни за централизиране на информацията, така
че да може по-лесно и по-ефикасно да се управляват наличностите и да се следят
поръчките и продажбите в един антикварен магазин, в който се работи с единични
екземпляри и редки предмети. За всеки предмет се съхранява информация за
наименованието, вида, цената, предложената цена на дребно и оценка на състоянието
на предмета; на състоянието на всеки предмет се поставя една от следните оценки:
отлично, много добро, добро, задоволително, лошо или повреден, като към всеки
предмет и всяка оценка е възможно да се добави и описание (няколко изречения). Тъй
като тези предмети са редки, всяко от тях трябва да се следи поотделно – дори за
предмети с еднакво наименование, следователно трябва да се използва уникален
идентификатор за всеки предмет. До момента е използван идентификатор на предмет с
8 знака, комбинация от букви и цифри. За видовете предмети се поддържа информация
за наименованието и описание на съответната категория от няколко изречения, от
които задължително е наименованието. Поддържа се информация за служителите в
магазина – име, фамилия, адрес, телефонен номер, ЕГН, дата на постъпване на работа,
дата на приключване (ако служителят вече не работи в магазина, в противен случай –
NULL) и заеманата длъжност. Възможно е добавяне на нови длъжности или променяне
на съществуващите; съхранява се кратко описание на задълженията към съответната
длъжност (или поне към някои от длъжностите). Всеки служител може да заема само
една длъжност в даден момент. В магазина се поддържа информация за клиентите
име, фамилия, телефонен номер, адрес; предметите, които е закупил и кога е направена
съответната покупка. От личната информация задължителна е име и фамилия.
Поддържа се архив на продажбите – всяка поръчка трябва да включва информация за
продадените предмети; за клиента, който ги е купил; за служителя, който е продал
предмета; датата на поръчката; общата сума на продажбата; дата на доставката или
получаване на предмета, която се въвежда след извършване на съответната доставка
или получаване. Една поръчка е приключила, ако предметите са платени и взети от
магазина или след като е платено и те са изпратени на клиента. Един предмет не може
да бъде взет от магазина или да се изпрати, ако не е платен. Във всяка поръчка се
включва начина на плащане и състоянието на поръчката. Начините на плащане са: в
брой, с чек или с кредитна карта. Състоянието на поръчката може да е едно от
следните: (1) да се достави, (2) клиентът ще я вземе, (3) изпратена или (4) взета.
Продадените предмети остават в списъка на предметите, но с някаква маркировка, че
този предмет е продаден.
3

Това е само предварителен преглед

За да разгледате всички страници от този документ натиснете тук.
Последно свалили материала:
ДАТА ИНФОРМАЦИЯ ЗА ПОТРЕБИТЕЛЯ
12 окт 2019 в 22:18 студент на 41 години от Русе - Русенски университет "Ангел Кънчев", факулетет - Природни науки и образование, специалност - Информатика, випуск 2020
14 яну 2016 в 18:01 в момента не учи на 39 години
 
Подобни материали
 

Лекционен курс “Езици и среди за програмиране в Интернет”

02 дек 2006
·
624
·
73
·
9,932
·
300
·
1

Ще разгледаме една реална информационна система, поддържаща online търговия с книги - системата позволява на потребителите: Да разглеждат електронен online каталог на книгите. Да разглеждат списък с най-търсените книги – този списък се актуализира...
 

Методология на търсене на информация в интернет

17 мар 2008
·
373
·
13
·
3,220
·
314

Във времената, когато информацията се е превърнала в един от основните производствени фактори наред с земята, труда, капитала и мениджмънта, процеса на нейното намиране и пълноценно използване все още не е напълно изяснен...
 

Microsoft Power Point (програма за презентации)

23 апр 2008
·
1,683
·
29
·
2,620
·
3,479
·
3
·
11

С MS Power Point могат да се правят слайдове (slides), подсещащи бележки, диплянки, скици и всичко това във вид на презентация (presentation). Power Point има мощни съветници, които стъпка по стъпка помагат за създаването и проектирането на презентации...
 

Системи с база от данни

21 апр 2009
·
279
·
33
·
8,226
·
348
·
3

Създаването на база от данни започва със събиране и анализ на данните за предметната област. Работата по проектиране на база от данни и нейната експлоатация може да бъде разделена на три различни нива...
 

Структуриран тип данни масив

17 мар 2006
·
528
·
3
·
289
·
109

Същност..Деклариране на данните тип масив..Описание в раздела за деклариране на променливите..
1 2 3 4 5 » 11
 
Онлайн тестове по Информатика, ИТ
Входно ниво по информационни технологии за 8-ми клас
входен тест по Информатика, ИТ за Ученици от 8 клас
Тестът е за упражнение и да определи входното ниво в началото на 8-ми клас по "Информатика и информационни технологии". Всеки въпрос има само един верен отговор.
(Лесен)
16
18
1
3 мин
11.07.2019
Периферни устройства
входен тест по Информатика, ИТ за Ученици от 11 клас
Тестът е подходящ за входно ниво по "Периферни устройства", ЗПП, XI клас. Всеки въпрос има само един верен отговор.
(Лесен)
10
7
1
1 мин
14.08.2019
» виж всички онлайн тестове по информатика, ит

Разработване на логически модел на данните

Материал № 447046, от 30 яну 2010
Свален: 24 пъти
Прегледан: 33 пъти
Предмет: Информатика, ИТ
Тип: Лекция
Брой страници: 14
Брой думи: 4,107
Брой символи: 24,878

Потърси помощ за своята домашна:

Имаш домашна за "Разработване на логически модел на данните"?
Намери бързо решение, с помощтта на потребители на Pomagalo.com:

Намери частен учител

Мирела Любенова
преподава по Информатика, ИТ
в град Асеновград
с опит от  2 години
11

Пенка Кръстева
преподава по Информатика, ИТ
в град Пловдив
с опит от  6 години
42

виж още преподаватели...
Последно видяха материала
Сродни търсения